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ABSTRACT 


This case study analyzes how the Stryker Mobile Gun System (MGS) 
program managed complexity. The MGS is one of the ten variants of the Stryker 
series of vehicles that equip the Army’s Stryker Brigade Combat Teams. These 
brigades were created by the Army Chief of Staff from 1999-2003, General Eric 
Shinseki, to provide the Army with a highly deployable medium-force capability. 
Initially intended as a variant that required limited development, the MGS 
experienced a number of significant challenges during systems development. 

This case study uses one of the program’s primary issues, reliability 
shortfalls with the ammunition handling system, to describe how the program 
self-organized to manage complexity. The case study identifies the elements of 
complexity that existed in the Defense Acquisition System (DAS), and how they 
interacted to create a challenging situation for the MGS program. 

After a crisis period from 2004-2005, the MGS program changed its 
acquisition approach through the revitalization of systems engineering and risk 
management. This case study examines the self-organizing methods that the 
MGS program used to improve system performance, and it concludes with a 
description of how acquisition programs can better align their acquisition strategy 


to achieve programmatic resilience. 
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I. INTRODUCTION 


A. DIYALA PROVINCE, 2008 


The platoon sergeant from Alpha Company, 1° Battalion, 38" Infantry 
Regiment had thoroughly prepared his Mobile Gun System (MGS) platoon for 
their reconnaissance mission in the Diyala Province, an area northeast of 
Baghdad that was a hotbed of insurgent activity. With over 19 years in the Army, 
the platoon sergeant understood the process of preparing Soldiers for a mission, 
known as Troop Leading Procedures, and he was aware of the potential 
problems that could easily arise in such a complex environment. The Army trains 
its tactical leaders to integrate the Troop Leading Procedures as early as 
possible in the planning process and to maximize the use of time. 

The platoon’s mission from their higher headquarters was to “get eyes on” 
a small town in their sector by using the sophisticated array of day and night 
optics on the MGS (see Figure 1) (Pappalardo, 2008, March 11). To visualize 
the battlefield, the platoon sergeant used the limited amount of information that 
he had on the enemy and the three-dimensional terrain to build situational 
understanding for the platoon, but he knew that this picture was imperfect. While 
moving to their observation point, the platoon sergeant’s MGS was struck by an 
improvised explosive device (IED) “that blew out eight tires and one antenna 
mount” (Pappalardo, 2008, March 11). Although the tremendous blast jarred the 
crew, they were able to execute one of their contingency plans and move the 
vehicle to a secure area 2600 meters away to execute their preplanned battle 
damage and repair procedures (Pappalardo, 2008, March 11). 

During mission planning, the MGS platoon leadership identified hazards 
and developed controls to mitigate those risks in a process known as risk 
management (TRADOC, 2005, November 20, p. E-1). The effectiveness of the 


risk management process requires situational understanding and controls that 
the platoon’s leadership adapts to the particular hazard and situation (TRADOC, 
2005, November 20, p. E-1). 





Figure 1. M-1128 MGS (From GDLS, 2005c, slide 2) 


Soon after they conducted the battle damage and assessment drill and 
brought the vehicle to an operational status, the platoon got back onto the road. 
Within minutes of getting the platoon back onto the road, a second IED struck the 
platoon sergeant’s vehicle (Pappalardo, 2008, March 11). This time, the crew’s 
gunner was able to identify “the triggerman on the roof of a building 820 feet 
away” and with no tires or communications equipment, the platoon sergeant’s 
vehicle was able to “engage the spotter with 20 rounds [7.62mm machine gun], 
while on the move to eliminate the threat” (Pappalardo, 2008, March 11). 
Despite two IED strikes, the platoon maintained its resiliency in the face of 
uncertainty and completed its mission without the loss of life. 

Risks are an inherent part of any mission, and the platoon was able to 
complete its mission because their leaders properly anticipated these risks and 
developed controls to reduce the severity of the consequences. During the 
mission, the platoon sergeant demonstrated the integration of risk management 


2 


and knowledge management into his Troop Leading Procedures. The 
synchronization of these processes was critical to his platoon’s ability to 
accomplish the mission without the loss of life. Yet, the synchronization of these 
processes required the application of the platoon sergeant’s will and an 
understanding of battle command. 


B. SYSTEMS ACQUISITION: A COMPLEX AND UNCERTAIN MISSION 


In a similar manner to the behavior of the tactical leader in the Diyala 
vignette, the program manager must synchronize his or her program in time and 
space to achieve effective results while navigating a complex and uncertain 
defense acquisition system. Just as the MGS platoon sergeant synchronized risk 
management and knowledge management into his Troop Leading Procedures, 
the program manager must do the same to exercise resilient and agile program 
management. The program manager must also work with imperfect information 
while making decisions on development, testing, production, and logistical 
support that will affect the program over its entire lifecycle. 

The Mobile Gun System, one of the ten variants of the Stryker series of 
vehicles, conducted its first operational deployment to Iraq as part of the 4" 
Stryker Brigade Combat Team, 2™ Infantry Division in 2007. During its first 
operational deployment to lrag, the MGS received positive feedback and in the 
words of the platoon sergeant from the Diyala vignette, “it is the most lethal 
ground vehicle for an urban environment in lraq today” (Pappalardo, 2008, March 


11). However, the vehicle experienced a challenging development process. 


C. RESEARCH QUESTION AND METHODOLOGY 


1. Research Question 


This case study had one primary research question: How did the Mobile 
Gun System Program Management Office (MGS PMO) manage complexity? 
From the primary research question, the research developed several supporting 


research questions: 


e What was a significant developmental problem experienced by MGS 
that required the MGS program to revise its approach? 

e What was the root cause of the developmental problem and what 
corrective actions did the program management office take to improve 
the system? 

e What is complexity theory and how does it apply to products and 
systems? 

e How did the MGS PMO self-organize to adapt to the complex 
environment and what insights can the case study use to apply to other 


systems acquisition programs? 


2. Methodology 


This case study focused on the program’s first six years of development 
from 2000-2006, which provided the case study with a historical perspective. 
The case study used a specific issue encountered during the MGS development 
as a means to study how complexity affected one particular systems acquisition 
program. The case study then identified the methods, techniques, and 
approaches that the MGS Product Management Office (MGS PMO) and the 
prime contractor, General Dynamics Land Systems (GDLS), used to manage the 
complexity. 

The first step in the research process was to obtain information for the 
case study from several different sources. The researcher focused on 
documents and information available through open sources such as defense 
publications and newspapers. The researcher then transitioned to a literature 
review on complexity theory. 

The next step in the research process was to interview members of the 
Project Management Office for the Stryker Brigade Combat Team (PM SBCT). 
Since the development of the MGS is still in progress, many of the program’s key 
participants were available for interviews. These interviews played a critical role 


in providing information for the case study. As part of the research process, the 


4 


author arranged interviews with current and former government and private 
sector individuals who were involved with the development of the MGS both 
directly and indirectly. 

According to Robert K. Yin, the author of Case Study Research, the 
researcher should approach a case study as an open-ended investigation (Yin, 
2003, p. 90). Each interview served as a source of information, but the research 
had to corroborate all of the information gained from the interview to present a 
clear and concise case. When conducting the interviews, the author focused the 
questions on, “satisfying the needs of [the case study’s] own line of inquiry while 
simultaneously putting forth friendly and non-threatening questions in open 
ended interviews” (Yin, 2003, p. 90). 


3. Limitations 


The case study attempts to fill some of the gap between the literature on 
complexity in the defense acquisition environment and the literature on how 
program management offices manage complexity. The case study uses a recent 
Army acquisition program to provide relevant lessons learned for acquisition 
professionals. 

The case study has two main limitations. First, it attempts to draw 
conclusions on how an acquisition program managed complexity by analyzing a 
segment in time, 2000-2006. The case study also focused on one specific 
development issue, reliability growth. The main limitation of this approach is that 
it does not fully address everything that the MGS PMO conducted during this 
period. 

Second, the author was able to interview a broad range of individuals from 
both the government and the private sector for the case study, but it is possible 
that bias existed within the interview content. To mitigate this, the author 
interviewed several individuals from multiple periods to increase the level of 


objectivity. 


D. ORGANIZATION OF THE CASE STUDY 


The case study specifically addresses one critical challenge of the MGS 
development, but in a wider sense, this is not the purpose of the case study. The 
discussion of the reliability shortfalls is merely a means of discussing how 
programs self-organize in the face of complexity. Therefore, it was necessary to 
start from a very broad perspective when addressing the Mobile Gun System 
program’s management of complexity. 

In Chapter |, the case study introduces the research question, the 
methodology, and the organization of the case study. The opening discussion on 
the Diyala vignette frames the case study’s analysis. 

Chapter Il, “What is Complexity,” introduces complexity theory, and it 
starts from a very broad perspective with a discussion of several different 
theories. As the chapter progresses, it focuses the discussion on complex 
programs. In addition to discussing complexity in programs, Chapter Il also 
discusses the use of systems engineering, risk management, and strategic 
planning. 

In Chapter Ill, “The Road to Stryker,” the case study provides a context to 
the outer environment that led to the Interim Force, which was later renamed 
Stryker. Chapter Ill discusses the Stryker’s champion, General Eric Shinseki, 
who articulated the vision for the Interim Force during the October 1999 
Association of the United States Army convention. “The Road to Stryker” also 
discusses how the acquisition reforms of the 1990s affected the Stryker program 
as well as the urgency of the program. 

Chapter IV, “The Development of MGS,” provides a more focused 
discussion on the MGS. In this chapter, the case study describes the unique 
requirements of the MGS and the approach that the program manager took in 
developing the system. Chapter IV also provides a chronological history of the 
development through 2008 to familiarize the reader with the program. 

Chapter V, “Managing Complexity,’ focuses on the reliability issues 


associated with the MGS ammunition handling system. The chapter then 
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analyzes how the program self-organized during a crisis. The chapter closes 
with a discussion on the application of complexity theory to the MGS. During this 
discussion, the author develops several insights on the key aspects of the 
program’s self-organization. 

Chapter VI, “Conclusion and Lessons Learned,” takes the insights from 
Chapter V and discusses program synchronization with a wider perspective. 
Chapter VI then closes with six lessons learned along with several 


recommendations for other systems acquisition programs. 
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ll. COMPLEXITY—A LITERATURE REVIEW 


A. INTRODUCTION 


To gain a greater appreciation for the concept of complexity in product 
development, this case study cast a broad net, starting with a review of several 
seminal perspectives on complexity. This literature review progressively scopes 
the subject of complexity from a broad discussion to one focused on products 
and systems. The purpose of this chapter is to describe the theoretical 
framework for the case study, with a focus on complexity. 

The MGS program encountered complexity both internally and externally 
during its development. Before delving into the nuances of the MGS program’s 
complex environment, it is important to understand the sources of complexity. 
Maier and Rechin (2000) provide a strong case for understanding the sources of 
complexity when studying technical problems: 

It is generally agreed that increasing complexity is at the heart of 

the most difficult problems facing today’s systems architecting and 

engineering. When architects and builders are asked to explain 

cost overruns and schedule delays, by far the most common, and 

quite valid, explanation is that the system is much more complex 

than originally thought. The greater the complexity, the greater the 

difficulty. (p. 24) 

It is not the intent of this literature review to provide an exhaustive review 
of all sources on complexity; rather, this chapter discusses how complexity 
relates to products and systems. This section provides several theoretical views 
on complexity, a description of complex products and systems, characteristics of 
management systems for complex systems, potential problems encountered with 
the management of complex systems, the use of the systems approach, risk 


management, and strategic planning in complex programs. 


B. WHAT IS COMPLEXITY? 


The term “complexity” frequently describes anything that consists of many 
interrelated parts or is difficult to explain in simple terms. One can easily find 
over thirty definitions of complexity from different sources, and this section will 
start by discussing three of these definitions. These perspectives are from Stuart 


A. Kauffman, Herbert A. Simon, and Peter M. Senge. 


1. Self-Organization 


In The Origins of Order, Kauffman (1993) provides a view of complexity 
from a physical and biological standpoint. Within a complex network, he 
discusses three regimes of behavior that include ordered, complex, and chaotic 
(Kauffman, 1993, p. 183). The complex regime is an area on the border between 
order and chaos. The dynamics of this complex regime are sensitive to the initial 
conditions and can easily change, based on the parameters. Once parameters 
are changed, Kauffman describes the small and large changes within the 
complex regime as “avalanches” that affect the entire system (1983, p. 174). He 
refers to systems that are able to adapt to the changes in parameters as “self- 
organizing,” and this occurs through the accumulation of useful variations 
(Kauffman, 1993, p. 174). While Kauffman addresses the complex regime that 
bordered on chaos and order, Simon sees complexity in hierarchical terms. 

In The Sciences of the Artificial, Herbert A. Simon (1981) refers to 
complexity as something that is “made up of a large number of parts that interact 
in a non-simple way” (1981, p. 195). Simon believed that complexity was 
hierarchical in nature and that each system within the hierarchy had its own 
unique sub-systems. He describes this as a “box within a box,” with each 
complex system consisting of both an inner and outer environment (Simon, 1981, 
p. 148). The outer environment serves as the operating environment for the 
inner environment, and the outer environment is the inner environment’s primary 
source of complexity. For its part, the inner environment is constantly adapting 


and insulating itself from the variations emerging from the outer environment; he 
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refers to this concept as a “design problem” (Simon, 1981, p. 134). The inner 
environment’s design quality also depends on the limited data available from the 
outer environment, and this leads to a high level of uncertainty and ambiguity. 

In Rationality as Process and as Product of Thought, Simon stated that “in 
complex situations there is likely to be a considerable gap between the real 
environment of a decision and the environment as the actors perceive it (1978, 
May, p. 8). When a decision maker addresses uncertainty and gaps in 
perception, he or she can either satisfice or seek an optimal solution. Satisficing 
occurs when the search for a solution “terminates when the best offer exceeds 
an aspiration level that itself adjusts gradually to the value of the offers received 
so far’ (Simon, 1978, p. 10). Optimizing occurs when the “correct point of 
termination is found by equating the marginal cost of search with the marginal 
improvement in the set of alternatives” (Simon, 1978, p. 10). In many situations, 
the uncertainty of the situation causes the decision-maker to arrive at intuitive 
decisions that are good enough. Two methods for satisficing are using “feedback 
to correct for unexpected or incorrectly predicted events” and feed-forward, which 
is “based on predictions of the future, in combination with feedback, to correct the 
errors of the past” (Simon, 1981, p. 44). Feed-forward requires some awareness 
of the predicted consequences of decisions. 

Feed-forward is challenging for organizations because people have 
difficulty maintaining awareness over such a large number of potentially relevant 
considerations (Simon, 1978, p. 8). Over time, these organizations learn “in the 
form of reaction to perceived consequences,” and this learning is the dominant 
way that rationality develops in an environment of uncertainty (Simon, 1978, p. 
8). The large number of potential considerations makes a situation or problem 
complex. The interrelated nature of these problems makes rational decision- 


making more difficult because of the second- and third-order consequences. 


2. Dynamic versus Detail Complexity 


Senge (2007), the author of The Fifth Discipline, differentiates problems 


that exhibit detail complexity and dynamic complexity. Detail complexity consists 
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of a brief snapshot in time of a relatively static system in which there are many 
different variables to explain cause and effect (Senge, 2007, p. 71). The 
preponderance of analytical and forecasting tools that are currently used address 
detail complexity. Problem-solvers who are accustomed to solving problems 
involving detail complexity frame the problem as a closed event in terms of time 
and space. However, the analytical and forecasting tools that use detail 
complexity do not provide a clear cause and effect with dynamic complexity 
because cause and effect are “subtle and the consequences of actions occur 
over time” (Senge, 2007, p. 71). Senge describes several situations in which 
dynamic complexity may exist including: 

When the same action has dramatically different effects in the short 

and long run [...], when an action has one set of consequences 

locally and a very different set of consequences in another part of 


the system [... and] when obvious interventions produce non- 
obvious consequences. (2007, p. 71) 


Senge believes that dynamic complexity was the source of most problems 
and that the key to understanding it was the identification of patterns and 
relationships in variables. Unlike the variables in detail complexity, the variables 
in dynamic complexity are interdependent and difficult to separate. Since most 
problem-solvers look at problems in terms of brief snapshots in time and in a 
relatively linear manner, finding the actual source of an issue is problematic. 
From Senge’s perspective, individuals should view a dynamic problem in a 
holistic manner with a systems approach. 

Senge also believes that the dynamic nature of these problems requires 
organizations that excel at learning. Complex and dynamic systems require 
cross-functional teams made up of “people who need one another to act” (Senge, 
2007, p. 219). The centerpiece of this effort is “collaborative learning,” where 
teams engage in open dialogue and explore complex issues from many 
perspectives (Senge, 2007, p. 221). Senge identifies three critical dimensions for 
team learning in organizations: 1) think insightfully about complex issues, 2) 


utilize innovative, coordinated action, and 3) understand the roles of team 
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members on other teams (2007, p. 219). A key impediment to the use of the 
systems approach is the existence of defensive routines that blur the facts or the 
reality of the situation. Effective teams can nullify these defensive routines by 
embracing conflicting ideas and by ensuring the free flow of information, both bad 
and good. 

The common theme within each perspective is that complexity occurs in 
many different environments and situations but mainly in moving or dynamic 


systems in which adaptation occurs in subtle and non-linear ways. 


C. COMPLEXITY IN PROGRAMS 


Both Kauffman (1993) and Simon (1981) view the outer environment as 
the primary source of complexity. In a similar manner, Marco lansiti (1995), the 
author of Technology Integration: Managing Technological Evolution in a 
Complex Environment views a complex product as the adaptation to 
“requirements from an organization’s existing environment” (p. 521). A product is 
the result of the fusion of technical concepts and existing knowledge within an 
organization. In his view, complexity in new product development originates from 
the requirements, sources of knowledge, and processes that lead to the creation 
of the product itself (lansiti, 1995, p. 522). For a comprehensive discussion of a 
Complex Product System, Mike Hobday (1998), the author of Product 
Complexity, Innovation and Industrial Organization, provides a clear definition 
and a list of factors that contribute to product complexity. 

Hobday (1998) defines a complex product or system as “any high cost, 
engineering-intensive product, sub-system, system or construct supplied by a 
unit of production” (p. 2). Many of these complex products are the result of new 
and emerging technology and involve “high levels of uncertainty and _ risk” 
(Hobday, 1998, p. 5). Hobday also provides a list of interdependent product 
dimensions that characterize complex products. These factors include: 

e Unit cost/financial scale of project, 

e Product volume, 


e Degree of technological novelty, 
13 


e Extent of embedded software in the product, 

e Quantity of sub-systems and components, 

e Degree of customization of components, 

e Complexity and choice of system architectures, 
e Quantity of alternative component design paths, 
e Feedback loops from later to earlier stages, 

e Variety of distinct knowledge bases, 

e Variety of skills and engineering inputs, 

e Intensity of user involvement, 

e Uncertainty/change in user requirements, 

e Intensity of other supplier involvement, and 


e Intensity of regulatory involvement (Hobday, 1998, p. 10) 


These product dimensions increase the difficulty of coordination and systems 
architecture, and they make coordination among contributing stakeholders an 
essential element of success. 

Robert W. Rykroft and Don E. Kash (1999) discuss complexity in product 
development in their book The Complexity Challenge: Technological Innovation 
for the 21° Century. Rykroft and Kash define technological complexity as “any 
technology that could not be understood in detail by an expert individual” (1999, 
p. 54). They provide several conceptualizations of product complexity that 
include the number of components in a system, the “relationship between 
process and product technologies,” and the use of feedback loops to self-adjust 
or self-correct system attributes known as cybernetics (Rykroft & Kash, 1999, p. 
55). They describe the complex systems emerging from technological innovation 
as a combination of craft production and mass production that are characterized 
by a “high degree of risk and uncertainty, a constant sense of novelty, a drive to 
solve new problems, and above all, a lot of trial-and-error searching and non- 
linear learning” (Rykroft & Kash, 1999, p. 28). 


The sense of novelty that characterizes the development of complex 
systems means that learning organizations must have a core competency in 
accumulating and transferring information as well as a proven process to reflect 
on new information (Rykroft & Kash, 1999, p. 62). The pressure of meeting a 
time-to-market requires the organization to embrace “error-embracing behavior” 
in order to gain insights on complex systems during their development (Rykroft & 
Kash, 1999, p. 63). However, error-embracing behavior does not produce 
substantial improvements in time-to-market unless organizations understand the 
importance of communication throughout the organizational network. 

These perspectives provide similar discussions on complex product 
characteristics, the use of feedback loops, self-correcting systems, and non- 
linear learning. The drive to field these complex systems at a faster rate while 
adapting to a changing environment requires a seamless relationship between 
technology and the organization. 


A Characteristics of Management Systems 


Numerous models provide a framework for creating a new product and 
managing its development. Roy C. Rothwell (1992), the author of Successful 
Industrial Innovation: Critical Factors for the 1990s, provides a useful description 
of five generations of innovation processes, starting in the 1960s. The first two 
generations of models describe “technology-push” and “need pull” as linear and 
sequential models of development (Rothwell, 1992, p. 221). The third generation 
model continues the use of a sequential process, but it also included the use of 
feedback loops. The fourth generation model of the 1980s went to the use of a 
parallel process to cut down on cycle-time and emphasized integration between 
R&D and manufacturing. The fifth generation model of the 1990s included the 
use of parallel processes and systems integration, with an emphasis on 
collaboration among organizations (Rothwell, 1992, p. 221). 

Although Hobday did not differentiate the five generations of industrial 
innovation, he concurred with Rothwell that complex products and systems do 


not follow the “conventional model” of development (Hobday, 1998, p. 18). He 
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emphasized that the key difference between complex products and systems and 
simple systems was user involvement because they were “individually developed 
and tailored [...] for a particular customer” (Hobday, 1998, p. 19). Rykroft and 
Kash (1999) strongly endorse the importance of strong collaboration between the 
user and the system developer. 

Rykroft and Kash contend that the use of the linear model works well with 
mature technology in a mass production environment but is ill-suited for the 
development of tailored, complex systems because it detracts from rapid 
decision-making (Rykroft & Kash, 1999, p. 59). The user and marketplace 
demand for complex technology requires a faster cycle-time using non-linear 
concurrent models. These models accentuate collaboration among many 
different organizations, firms, and agencies and “error-embracing behavior” 
(Rykroft & Kash, 1999, p. 63). To reduce cycle-time, Rothwell identified a 
number of factors that influenced a “time-based strategy” including those listed 
below. 

e Adequate preparation: careful project evaluation, analysis, and 
planning as well as gaining the commitment of those who will be 
involved in the project, 

e Efficient indirect development activities: project control, administration, 
and coordination 50% of total project time, 

e Adopting a more horizontal management style with increased decision- 
making at lower levels, 

e Efficient upstream data linkages and an_ inter-company liaison: 
involving primary suppliers at an early stage of development, 

e Use of integrated teams during development and prototyping, 

e Modifying the development process: maximizing the use of simulation 
models through the use of expert systems, 

e Incremental improvement strategy: continuous improvements of 


existing products, 
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e Carry-over strategies: use of significant elements of earlier models in 
the most recent designs, 

e Designed-in flexibility: creation of flexible designs, 

e Fuller organizational and systems integration: minimize number of 
reporting layers, and 

e Fully developed internal data base (1992, p. 234-235) 


Although Rykroft and Kash contend that the linear model is inadequate for 
innovating complex technology, they admit that the non-linear and dynamic 
system is crisis-oriented and messy. They apply the term, “self-organizing,” to 
the description of networks of leaders, knowledge workers, and groups who 
share risk and information across organizational boundaries (Rykroft & Kash, 
1992, p. 90). The second pillar, “evolutionary learning,” is the imperfect and 
messy process of integrating and testing components while applying knowledge 
to keep pace with technological progress (Rykroft & Kash, 1992, p. 135). 

While Rykroft and Kash impart a conceptual perspective on the 
management of complex products and systems, lansiti offers some best 
practices for technology integration. Like most of the authors mentioned, he 
subscribes to a systems approach as the best means of problem solving and 
decision-making, and he points out that the most important period of a 
technology integration project is during project specification. During this stage, 
he accentuates the importance of a broad and informed approach to framing 
problems and searching for solutions through multiple contexts (lansiti, 1995, p. 
525). 

Several authors emphasized the crisis-oriented approach to the 
development of complex products and systems. While the non-linear approach 
may cut down on cycle-time, it requires several critical inputs such as a high 
degree of trust among organizations, risk acceptance, and capturing and 
disseminating knowledge to stakeholders in a timely manner. The next section 
highlights several of the potential problem areas that programs encounter when 


they manage complex systems using a non-linear approach. 
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2. Common Managerial Problems with Complex Programs 


In his article Managing Innovation in Complex Product Systems, Howard 
Rush (1997) identified three “hotspot” categories: 1) requirements identification, 
2) coordination of information, and 3) process issues (p. 4/2). The considerable 
time pressures that differentiate complex products and systems often lead to 
inadequate system requirements that necessitate later revision. The intensity of 
organizational coordination in complex products and systems also requires the 
diffusion of explicit and tacit knowledge—a typical coordination issue. Another 
problem that permeated these types of programs is the lack of adequate staffing 
due to the exigent nature of the program’s formation. The lack of staffing is a 
potential cause of short cuts taken in processes and best practices (Rush, 1997). 

Although several of the authors advocated following a less linear and 
sequential model of development for complex products and systems, they all 
advocated following some type of process. Nelson P. Repenning (2001) 
discusses the potential impact of not following a process during new product 
development in his paper Understanding Fire Fighting in New Product 
Development. In the context of product development, Repenning describes fire 


fighting as the “unplanned allocation of engineers and other resources to fix 
problems discovered late in a product’s development cycle” (2001, p. 5). He 
believes that dedicating a large number of resources to fighting fires takes away 
valuable resources from other critical project activities. He attributes the 
persistent fire fighting mentality to organizations that do not possess an in-house 
capability for organizational learning. These organizations also fail to allocate 
resources, and they attribute the cause of their problems to the “attitude and 
disposition of the people working within the process rather than to the structure of 


the process itself’ (Repenning, 2001, p. 25). 


3. Applying the Systems Approach 


A common theme in this literature review is that most complexity problems 


are dynamic in nature. “Systems thinking’ is a holistic approach to 
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understanding and comprehending the many variables present in dynamic 
situations. Senge fully advocates the adoption of systems thinking when he 
says, 

we tend to focus on snapshots of isolated parts of the system, and 

wonder why our deepest problems never seem to get solved. 

Systems thinking is a conceptual framework, a body of knowledge 

and tools that has been developed over the past fifty years, to 

make the full patterns clearer, and to help us see how to change 

them effectively. (2007, p. 7) 

As a conceptual framework, the systems approach attempts to make sense of 
systems that have many interrelated parts. During product development, the 
practical means of realizing the systems approach is through the discipline 
known as systems engineering. During the post-World War Two period, systems 
engineering emerged as a means to develop solutions to dynamic problems. 
Systems engineering takes the insights gained from systems thinking “with an 
orientation toward the engineering and analysis of technical systems” (Blanchard 
& Fabrycky, 2006, p. 19). 

The Institute for Electrical and Electronics Engineers (IEEE) defines 
systems engineering as “an interdisciplinary collaborative approach to derive, 
evolve, and verify a lifecycle balanced solution which satisfies customer 
expectations and meets public acceptability” (1994, p. 11). The International 
Council on System Engineering (INCOSE) defines systems engineering as 

an interdisciplinary approach and means to enable the realization of 

successful systems. It focuses on defining customer needs and 

required functionality early in the development cycle, documenting 
requirements, and then proceeding with design synthesis and 
system validation while considering the complete problem. Systems 

Engineering considers both the business and the technical needs of 

all customers with the goal of providing a quality product that meets 

the user needs. (2006, June, p. 1.18) 

The Defense Acquisition Guidebook, defines systems engineering in this 


way: 


Systems engineering is the overarching process that a program 

team applies to transition from a stated capability need to an 

operationally effective and suitable system. Systems engineering 

encompasses the application of systems engineering processes 
across the acquisition lifecycle (adapted to each and every phase) 

and is intended to be the integrating mechanism for balanced 

solutions addressing capability needs, design considerations and 

constraints, as well as limitations imposed by technology, budget, 

and schedule. The systems engineering processes are applied 

early in concept definition, and then continuously throughout the 

total lifecycle. (2008, p. 4.1) 

The common theme among these definitions is the focus on meeting a user's 
needs through an interdisciplinary approach to solving technical problems with a 
lifecycle orientation. 

In accordance with the DoD Directive 5000.1, The Defense Acquisition 
System, the use of the systems engineering process is the official policy of the 
DoD, and it will “optimize system performance and minimize total ownership 
costs” (Under Secretary of Defense (AT&L), 2003a). The DoD program manager 
is empowered to develop a tailored systems engineering approach for a 
particular program that will integrate systems engineering processes throughout 


a product's lifecycle. 


4. Use of Risk Management 


Simon described the difficulty of rational decision-making under 
uncertainty when he said, “reasonable men reach reasonable conclusions in 
circumstances where they have no prospect of applying classical models of 
substantive rationality” (Simon, 1978, p. 14). Complex programs that are unable 
to manage complexity and uncertainty will quickly fall into a resource-intensive 
fire-fighting mode (Repenning, 2001). 

Complex programs must adapt to an outer environment that consists of a 
large number of risk factors and considerations that are interrelated. Ultimately, 
this leads to an environment of uncertainty and ambiguity. Programs categorize 
risk as either internal or external. In the article, On Uncertainty, Ambiguity, and 


Complexity in Project Management, Pich, Loch & DeMeyer expressed 
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uncertainty and ambiguity in terms of “information adequacy” (2002, p. 1008). 
External risk is more difficult to mitigate and often falls into the category of 
“unknown-unknowns” (Pich et al., 2002, p. 1019). Ambiguity is an unknown- 
known, and it occurs when a program lacks awareness of a particular problem 
but is able to improve the availability of information about the unknown through 
the expenditure of resources (Pich et al., 2002, 1013). This is in contrast to 
“unknown-unknowns” that exist and exert a significant impact on complex 
programs but are completely unforeseen by a program manager (Pich et al., 
2002, p. 1019). 

The proactive and consistent management of risk is an essential element 
of successful projects (PMI, 2004, 240). The risk management process assumes 
that problems are recognizable through the early identification of signals that 
indicate a potential problem. The Risk Management Guide for DoD Acquisition 
defines risk as “a measure of future uncertainties in achieving program 
performance goals and objectives within defined cost, schedule, and 
performance constraints” (DAU, 2006, August, p. 1). Furthermore, it organizes 
risk into three components: 1) a future root cause, 2) a probability or likelinood, 
and 3) a consequence or effect (DAU, 2006, August, p. 1). The Risk 
Management Guide for DoD Acquisition emphasizes the use of risk management 
throughout a program's lifecycle by suggesting a strong integration with the 
systems engineering and test and evaluation processes. The Risk Management 
Guide also identifies several common risk-related attributes to successful 
programs: 

e Feasible, stable, and well-understood user requirements, 
supported by leadership/stakeholders, and integrated with 
program decisions; 

e Aclose partnership with users, industry, and other stakeholders; 

e A planned risk management process integral to the acquisition 
process, especially to the technical planning (SEP and TEMP) 


processes, and other program related partnerships; 
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e Continuous, event-driven technical reviews to help define a 

program that satisfies the user’s needs within acceptable risk; 

e Identified risks and completed risk analyses; 

e Developed, resourced, and implemented risk mitigation plans; 

e Acquisition and support strategies consistent with risk level and 

risk mitigation plans; 

e Established thresholds and criteria for proactively implementing 

defined risk mitigation plans; 

e Continuous and iterative assessment of risks; 

e The risk analysis function independent from the PM; 

e A defined set of success criteria for performance, schedule, and 

cost elements and a formally documented risk management 
process. (DAU, August, 2006, p. 5) 

Every program has some element of risk whether they know it or not, and 
it is the basic responsibility of any manager of a complex program to manage 
risk. A major determinant to a program manager's ability to manage risk is the 
program’s strategic approach. 


5. Strategic Planning 


Complex programs require a significant degree of coordination and 
synchronization to achieve their objectives and overcome ill-structured problems. 
Approaching ill-structured problems requires the program manager (PM) to 
engage in a process known as strategic planning. Simon (1976) described 
strategy as a “time binding” process in which “a series of decisions determine 
behavior over a certain stretch of time” (p. 67). Porter discussed strategy in 
terms of different and unique positioning. He defined strategy as “the creation of 
a unique and valuable position, involving a different set of activities,” which 
involves positioning a “tailored set of activities” (Porter, 1996, p. 68). Porter also 
stated that the “essence of strategy is choosing what not to do” (Porter, 1996, p. 
70). 
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Porter emphasized three types of “fit” for an organization: 1) simple 
consistency, 2) reinforcing, and 3) optimization of effort (Porter, 1996, pp. 71-73). 
Consistency occurs when an organization communicates a common message 
and the organization’s activities reflect a “single-minded” approach to meeting 
objectives (Porter, 1996, p. 71). The reinforcement of fit occurs when activities 
strengthen and build on one another similar to the manner in which risk 
management reinforces systems engineering (Porter, 1996, p. 72). The 
optimization of effort occurs when an organization’s activities are coordinated 
and minimize the amount of wasted effort. While strategies consist of many 
interrelated activities, it is essential to keep in mind that the whole matters more 
than the any individual part (Porter, 1996, p. 73). 

In terms of complex acquisition programs, the Defense Systems 
Management College (DSMC) defines strategy as a “framework for planning, 
organizing, staffing, controlling, and leading a program,” that is designed to 
“achieve program objectives within specified resource constraints” (1999, p. 1-1). 
Programs also tailor strategies to the goals, objectives and customer or user 
expectations with the goal of achieving resilience and stability over time (Porter, 
1996, p. 66; DSMC, 1999, p. 1-1, 1-2). Strategy is also a means for program 
leadership to set clear priorities, integrate program activities, and serve as a 
decision-making aid for individuals throughout the organization (Porter, 1996, p. 
69; DSMC, 1999, p. 1-4). 

Specific to defense programs, there are five characteristics to acquisition 
strategy: 1) realism, 2) stability, 3) resource balance, 4) flexibility, and 5) 
managed risk (DSMC, 1999, p. 2-1). Changes to an acquisition strategy often 
result in changes to a program’s overall risk level, and therefore, the project 
leadership must flexibly adjust the acquisition strategy to changes in the 
environment (DSMC, 1999, p. 2-7). The acquisition strategy should also serve 
as a guide for program stakeholders on how the program will operate in all 
phases of a product’s lifecycle (DSMC, 1999, p. 3-10). 
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D. CONCLUSION 


The purpose of this chapter was to provide a theoretical framework for this 
case study, with a focus on complexity. Complex programs, particularly those 
using a time-based strategy of fielding, require a unique set of considerations to 
achieve success. The MGS clearly falls into the category of a complex system, 
and the MGS program certainly embraced a dynamic self-organization to adapt 
to the outside environment. The next chapter provides a context to the outer 


environment of the Stryker program. 
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lll. THE ROAD TO STRYKER 


A. INTRODUCTION 


We [the Army] discovered that most of our heavy equipment, in a 
country that was wrestling to reestablish itself economically, tore 
their roads up so badly that commerce could not get through. And 
then we had to come back in and repair those roads (as cited in 
Hillen, 2000). 


General Eric Shinseki’s observation could describe any number of 
situations in lraq or Afghanistan. However, General Shinseki’s comment 
describes road conditions encountered in Bosnia in 1997. As the Chief of Staff of 
the Army (CSA) from 1999-2003, it was his responsibility to set the Army’s 
azimuth and ensure that the Army could meet all of its obligations in accordance 
with the National Security Strategy and National Military Strategy. For General 
Shinseki, the fundamental problem was to determine what the Army should be 
for the next 30 years. Through this exercise, he identified a clear capability gap 
between the evolving strategic environment and the Army’s existing capabilities 
(Hillen, 2000). 

To close this gap, he initiated a transformational strategy for the Army that 
he anticipated would last from 1999 to 2030. Sustaining this long-term strategy 
required a series of incremental changes to provide “irreversible momentum” 
(Shinseki, 2003). Embedded within Army Transformation was_ the 
implementation of the Interim Force (renamed the Stryker Brigade Combat Team 
in 2002), which ultimately served as the catalyst and initial increment of Army 
Transformation (Shinseki, 2001, p. 12). 

The purpose of this chapter is to understand the origins of the Mobile Gun 
System as part of Stryker. The background includes a description of the evolving 
strategic environment of the 1990s, the strategy of Army Transformation, the 
Interim Force operational requirements, and the subsequent selection of the 
materiel solution for the Interim Armored Vehicle (IAV) requirement. 
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B. STRATEGIC CONTEXT: AN UNCERTAIN AND _ VOLATILE 
ENVIRONMENT 


The end of the Cold War brought an increase in small-scale contingencies 
that intensified the demand for ground-force commitments. Fiscally, the 
decreasing size of defense budgets constrained fiscal resources and forced a 
more disciplined prioritization of effort. Economically, the United States 
experienced a prolonged period of growth that enabled an intensive investment 
in private sector research and development and led to an increasingly integrated 
global community. Technologically, the availability of information technology was 
rapidly improving the availability of relevant and real-time information. The Army 
found itself on a new playing field, yet it still had the same doctrine, organization, 
and culture from the Cold War period. The next section discusses the increase 


in small-scale contingencies and the Army’s structural misalignment. 


1. A New Focus on Small-scale Contingencies 


Throughout the 1990s, unpredictable events caused the United States to 
place the Army into a number of potentially disastrous situations such as early 
Desert Shield in 1990, Somalia in 1993, Haiti in 1994, Bosnia in 1997, and 
Kosovo in 1999. A rapid commitment of ground forces to remote regions 
characterized these deployments. An example of a potentially disastrous 
situation occurred shortly after lraq’s invasion of Kuwait in August 1990. The 
U.S. lacked a medium force that could rapidly respond to an Iraqi invasion of 
Saudi Arabia, and it committed the lightly equipped 82° Airborne Division as a 
stopgap measure. The Army essentially “held its breath” as this unit secured the 
border against several divisions of Iraqi armor until heavy U.S. units arrived 
(Hillen, 2000). Several years later, a company of Rangers incurred heavy 
casualties while operating without the benefit of armored vehicles in the 
congested streets of central Mogadishu. Soon thereafter, the deployment of 
heavy armor, such as M-1 tanks, to the Balkans was restricted due to the narrow 


roads and weight-restricted bridges in the region. 
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Concurrent with the increase in small-scale contingencies was the growing 
prevalence of information technology. The availability of information technology 
allowed sub-national and transnational groups to improve their ability to 
communicate and coordinate their efforts (Shinseki, 2001, p. 4). The multi-polar 
international security environment was increasingly vulnerable to the criminal and 
terrorist elements that used asymmetric tactics to achieve their limited objectives. 

These examples demonstrated a pattern of contingency deployments to 
geographically remote areas under uncertain political and operational conditions. 
During the 1990s, United States reduced the size of the Army from 781,000 to 
479,426, despite the Army’s role as the nation’s primary “military to military 
engagement tool for influencing policies and actions of other nations” (Shinseki, 
2001, p. 2). The smaller Army was clearly stretched, and its operational tempo 
increased from one deployment every four years to one deployment every 
fourteen weeks following the collapse of the Berlin Wall in 1989 (Shinseki, 2000, 
p. 22). 

General Shinseki saw the Army’s contribution to stability as “peacetime 
engagement, crisis management, deterrence, and the kind of rapidly deployable, 
overwhelming combat power that enables such capabilities” (Shinseki, 2000, p. 
22). His ladder of inference pointed towards an impending crisis on the nation’s 
strategic horizon. 


2. Dealing with Army Structural Misalignment 


These developments revealed a structural gap in the Army’s capabilities. 
Simply put, the Army organized itself for either “high-end” or “low-end” conflict 
(Shinseki, 2000, p. 23). The decreasing emphasis on high-intensity conflict and 
the prevalence of small-scale contingencies urgently necessitated a force 
optimized for these conditions--specifically a force that fell in a “medium” range 
between the existing high- and low-end formations. 

Ten years after the end of the Cold War, the Army retained a mix of heavy 
and light “Legacy” formations that it organized on the Cold War paradigm. The 
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light formations were capable of rapid deployment, but they lacked sufficient 
lethality, survivability, and mobility to engage a more heavily equipped adversary. 
On the other hand, the heavy formations were extremely lethal and survivable, 
but they depended on enormous transportation assets that required well- 
developed airfields and seaports at the destination point. The Army lacked a 
medium capability that could provide a mix of heavy and light capabilities. To 


address this urgent situation, General Shinseki initiated Army Transformation. 


C. THE VISION: INITIATE IRREVERSIBLE MOMENTUM 


General Shinseki was concerned that the Army could potentially become 
irrelevant if it did not adapt to the changing environment. Its current force 
structure was difficult to deploy and, in many ways, was a liability. 


1. General Shinseki’s Ladder of Inference 


Recognizing the Army’s shortcomings, General Shinseki initiated changes 
that led to a force that could dominate the full spectrum of conflict, not just the 
high and low ends. He saw the next major contingency occurring in a place like 
Central Asia or East Timor, not the North German Plain. General Shinseki 
underscored how important it was to change the Army when he stated: 

Frankly, the magnificent army that fought in Desert Storm is a great 

army [...]. But it was one we designed for the Cold War, and the 

Cold War has been over for ten years now. As we look forward to 

the next century, we've seen a bit of what that next century is going 


to look like, and the kinds of deployments we've had in the last ten 
years. (as cited in Hillen, 2000) 


General Shinseki was also concerned that the Legacy Forces were overly 
dependent on predictable air and sea debarkation points that were easy targets 
for a future adversary. Consequently, he made it a requirement to insert an Army 
brigade anywhere in the world, including austere airfields, within 96 hours 
(Shinseki, 2000, p. 28). The end state of the Army’s Transformation was the 
Objective Force, later known as the Future Combat System (FCS). Through 
Army Transformation, the Objective Force would be operational starting around 
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2010. To hedge the capability gap, General Shinseki modernized the Legacy 
Forces, and created the Interim Force. General Shinseki’s ladder of inference 
created a tremendous sense of urgency for change. The ladder of inference 
forced him to confront the brutal fact that the Army faced potential irrelevance if it 


did not close the medium-force capability gap (see Figure 2). 
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Figure 2._ The Urgency Behind the Interim Force Caused by the Medium- 
force Capability Gap 


2: A Time-Based Change Strategy 


The purpose of the Interim Force was to serve as the bridge between the 
current capabilities and the Objective Force. The Interim Force would provide 
the medium-force capability, as well as insights on doctrine, organization, and 
technology for the Objective Force (Shinseki, 2000, p. 28). The Interim Force 
was also the vital link for General Shinseki’s change strategy, and he placed 


command emphasis on its urgency. With a four-year time horizon as the CSA, 
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General Shinseki understood that the Interim Force concept was the foothold for 
Army Transformation. In a later interview with PBS Frontline, General Shinseki 
said, 

In my case, the appointment is for four years. As I've looked back 

at the tenures of other chiefs, generally the good ideas that found 

their way into implementation are the ones that were begun early 

[...]. | just believe that I've got to get the momentum early. That’s 

important to transformation, and my contribution to wherever 

transformation ends up happening is providing that momentum so 


that future chiefs can build on it [...]. Generally, it’s the first two 
years that'll make the difference. (as cited in Hillen, 2000) 


The urgent nature of the capability gap necessitated the selection of an 
Interim Armored Vehicle (IAV) that was immediately available. The urgent nature 
of the threat and his ability to transform the military necessitated the adoption of 
a time-based transformation strategy. General Shinseki stipulated that this 
vehicle be an “off-the-shelf system” for procurement in FY2000 (Shinseki, 2001, 
p. 12). According to Lieutenant General Paul J. Kern, the Military Deputy to the 
Assistant Secretary of the Army for Acquisition, Technology and Logistics at the 
time of the IAV selection, General Shinseki continuously pushed the Army to 
move faster with the selection of the materiel solution for the IBCT (Federal News 
Service, 2000). 


Furthermore, General Shinseki’s four-year time horizon as the Chief of 
Staff of the Army played a critical role in driving the IAV schedule, and he 
provided highly detailed direction over decisions that might have an impact on its 
success. This oversight included the review and approval of the [AV Request for 
Proposal (RFP) (Baumgardner, 2000, April 7). 


General Shinseki’s time horizon as the CSA acted as the upper parameter 
for the Mobile Gun System’s development schedule. Within the IAV Source 
Selection Plan, originally published in March 2000, the time for those vehicles 
requiring “extended variant/configuration development” was not to exceed 24 
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months, which included government testing (Kern, 2000). In effect, the 
developmental strategy for the MGS was time-based, not event-based, from the 
very beginning. 

The intent of the Interim Force concept was to have a combat formation 
that was packaged at the Aerial Point of Embarkation (APOE) and immediately 
available for operations upon arriving at its destination (PM BCT, 2000, p. 11). 
That capability provided the Army with a unique ability to place a large, well- 
equipped force deep into a threat environment. The Interim Force could use 
operational maneuver to go where it was least expected while having the 
capability to sustain itself and fight. General Shinseki, however, had a holistic 
view of Transformation, and it clearly encompassed more than just a new 
vehicle. He said: 

As we talk about transformation, we intend to get into the design of 

our units [...]. AS we reduce the size of our platforms, we also 

reduce the size of this rather significant logistical footprint, and that 

gives us the kind of agility that will put us in places that are least 


expected. We can reduce our predictability and get in there faster. 
(as cited in Hillen, 2000) 


His approach was highly aggressive, with an IAV procurement starting in 
FY2000 and an initial operational capability by FY2002. The unique Interim 
Force requirements also reflected a change in the way that the government 
approached acquisition programs. 


D. ACQUISITION REFORMS OF THE 1990s 


The IAV program was among the vanguard of programs in the 
government’s effort to revamp and streamline defense acquisition. During the 
1990s, the government passed a series of legislative reforms with the intention of 
aligning defense acquisitions with the market-based model found in the 
commercial sector. The driver of these changes, Dr. William J. Perry, the 
Secretary of Defense from 1994-1997, wanted to access commercial industry, 
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move away from a separate defense industry, achieve near-term cost savings, 
and capitalize on the technology advances of the commercial sector (“DoD News 
Briefing,” 1995). 

The primary components of the legislative reform of the government’s 
acquisition system were the Federal Acquisition Reform Act (FARA), the Federal 
Acquisition Streamlining Act (FASA), and the Services Acquisition Reform Act 
(SARA). The streamlining of government acquisition regulations also allowed for 


a considerable downsizing of the government's civilian acquisition workforce. 


1. Use of Performance Specifications over Government 
Specifications and Standards 


One of the more significant elements of these acquisition reforms that 
affected the IAV program was the reduction or elimination in processes for 
specifications and standards. Previously, the government relied on a wide range 
of military specifications (MilSpec) and military standards (MilStd) to guide the 
contractor on what processes and materiel to use in developing and producing a 
system. The Defense Standardization Program Policies and Procedures (DoD 
4120.24-M) defines a defense specification as “a document that describes the 
essential technical requirements for purchased materiel that is military unique or 
substantially modified commercial items” (Under Secretary of Defense (AT&L), 
2000, 67). 

The purpose of the specification and standards reform movement was to 
allow the contractor to exercise more initiative, infuse innovation into product 
development, and shift to a performance-based specification. In relinquishing 
some elements of design-oversight and allowing the commercial sector to find 
the materiel solution, the challenge for the government was how to “clearly 
describe technical requirements and provide sufficient verification to assure that 
products meet the users’ needs” (Millett & Gillis, 1998, p. 72). 
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2. Use of Non-Developmental Items (NDI) and Commercial Off- 
the-Shelf (COTS) 


With a drive for a peace dividend following the end of the Cold War, the 
DoD had fewer funds available for research and development. The decrease in 
research and development funding required the DoD to look towards the private 
sector for products and services that were immediately available. The DoD 
termed these items as either Non-Development Items (NDI) or Commercial Off- 
the-Shelf (COTS). 


In a June 2000 report, the Office of the Secretary of Defense (OSD) 
provided a list of best practices and lessons learned for NDI and COTS. The 
report defined a COTS item as: 

one that is sold, leased, or licensed to the general public; offered by 

a vendor trying to profit from it; supported and evolved by the 

vendor who retains the intellectual property rights; available in 

multiple, identical copies; and used without modification of the 

internals. (Gansler, 2000, July, p. 3) 

The DoD aggressively pushed to maximize the use of COTS and NDI to reduce 
cycle-time, increase the pace of new technology insertion, improve reliability and 
availability, and lower the total lifecycle costs (Gansler, 2000, July, p. 2). COTS 
are a subset of NDI and are defined as: 

Items that are used exclusively for government purposes by a 

Federal Agency, a state or local government, or a_ foreign 

government with which the United States has a mutual defense 

cooperation agreement; and any item described here that requires 

only minor modifications of the type customarily available in the 


commercial marketplace in order to meet the requirements of the 
processing department or agency. (Gutierrez, 2002, p. 66) 


While the intent of NDI and COTS was to “simplify and accelerate the acquisition 
process,” the use of NDI and COTS also incurred programmatic risk (Steves, 
1997, p. 40). Among the risks associated with NDI and COTS are the 1) form, fit, 
and function characteristics, 2) ability to adapt interface and data standards, 3) 
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vendor's anticipated and intended use of the NDI and COTS, 4) vendor’s test 
approach, and 5) the government’s ability to verify vendor test results (Gutierrez, 
2002, p. 68). 


3. IAV Request for Proposal (RFP) 


When the IAV Program Management Office released the draft RFP in 
December 1999, it did not contain detailed specifications because the program 
manager wanted to provide the contractor with the maximum amount of flexibility 
in tailoring their proposals (Dawson, 2001, p. 56). The final RFP, published in 
April 2000, contained a performance-based Statement of Work (SOW) founded 
on the Operational Requirements Document (ORD); it also contained only seven 
government specifications and standards (Dawson, 2001, p. 76, 95). The final 
RFP also allowed the possibility of awarding separate contracts for the Infantry 
Carrier Variant (ICV) and for the Mobile Gun System variant (Baumgardner, 
2000, April 10). The government presented four alternatives for contract awards 
in the RFP: 1) one award for the ICV variants and MGS variant, 2) one award for 
ICV variants and one award for the MGS, 3) one award for the ICV variants only, 
or 4) one award for the MGS only (Gamboa, 2001, April 9, 4). 

Working closely with the materiel developer, the Training and Doctrine 
Command (TRADOC) conducted a parallel effort to develop the operational 
requirements. Although the government could request a waiver to use military 
specifications and standards through the Milestone Decision Authority (MDA), the 
waiver process was long and generally discouraging because the DoD was trying 
to move away from the old ways of doing business. It was not until 2005 that the 
DoD eliminated the waiver policy to increase the program manager's flexibility to 
cite military specifications and standards within a solicitation or contract (Kratz, 
2005). 


E. A NEW APPROACH: INTERIM FORCE REQUIREMENTS 


The Interim Force requirements reflected the ambiguous and uncertain 


threat model of the 21° century. The Army chose a new and innovative path to 
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the Interim Force when it transitioned from a threat-based to a unit-based 
approach to requirements. The next section discusses the transition of 


requirements concepts, the Stryker operational tenets, and the source selection. 


1. Transition from Threat-based to Unit-based Requirements 


In previous armored vehicle acquisitions, the Army developed 
requirements based on a clearly defined threat. During the Cold War period, the 
Army could draw on abundant amounts of information about known threat 
systems. For instance, the Army developed the requirements for the M-1 
Abrams Tank and the M-2 Bradley Fighting Vehicle to counter a known spectrum 
of Warsaw Pact platforms and tactics. Although both vehicles functioned as part 
of a combined arms team, the Army did not stipulate a requirement for 
commonality. Additionally, these systems went through a deliberate systems 
development process that included several iterations of technology insertion 
(COL Robert Schumitz, PM SBCT, personal communication, January 29, 2009). 
The Interim Armored Vehicle (IAV) was the Army’s first new armored combat 
vehicle since 1981, and the Army saw an opportunity to improve efficiency and 
effectiveness with a new approach (Federal News Service, 2000). 


The Army designed a new type of brigade from the ground up that it 
designated as the Interim Brigade Combat Team (IBCT). The Army intended for 
the Interim Armored Vehicle (IAV) to serve as the common vehicle platform to 
meet the unit’s holistic requirements. The requirements for the Stryker were 
captured in the Operational Requirements Document, written by the user 
community and describing the system’s intended mission and the anticipated 
operational and sustainment concepts. The Medium Armored Vehicle 
Operational Requirements Document (ORD) broadly described the threat in this 
way: 

Asymmetric warfare focuses whatever may be one _ side’s 

comparative advantage against an enemy’s relative weakness. A 


defining and distinguishing aim of asymmetric warfare is the 
creation of conditions where the enemy’s relative advantage cannot 
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be applied is degraded or neutralized [sic]. The IBCT [Interim 
Brigade Combat Team] will be employed worldwide, wherever US 
interests are threatened. To this end, potential threat forces will be 
armed with various mixes of increasingly sophisticated weaponry. 
(Federation of American Scientists, 2000) 
The Army determined that it wanted a medium unit capability that could function 
in the both the “full spectrum environment” and small-scale contingencies 
(Federation of American Scientists, 2000). Upon achieving its full operation 
capability, the Interim Force would prevent the Army from becoming irrelevant 
through the ability to insert a “credible combat force on the ground anywhere in 
the world in 96 hours from liftoff’ (Panel on Operational Test Design and 
Evaluation of the Interim Armored Vehicle, 2004, p. 117). 


2. Interim Brigade Combat Team (IBCT) Operational Concept 


The ORD for the Stryker defines the top-level operational capabilities 
desired for the IBCT as well as the system-level capabilities for the IAV itself 
(Panel on Operational Test Design and Evaluation of the Interim Armored 
Vehicle, 2004, p. 117). The ORD describes the top-level capabilities of the IBCT: 


As a full spectrum combat force, the IBCT is capable of conducting 
all major doctrinal operations including offensive, defensive, 
stability, and support actions. Its core operational capabilities rest 
upon excellent operational and _ tactical mobility, enhanced 
situational understanding, combined arms integration down to the 
company level, and high dismount strengths for close combat in 
urban and complex terrain. Properly integrated through a mobile 
robust C4ISR network, these core capabilities compensate for 
platform limitations that may exist in the close fight, leading to 
enhanced force effectiveness. When employed in the operational 
environment for which it is optimized, the IBCT has the capability to 
achieve decision as a result of its early entry, shaping, and decisive 
actions. (Federation of American Scientists, 2000) 


The ORD describes the combined arms approach of the IBCT and its maneuver 


advantages. Unlike the Legacy Forces, the Army intended for the IBCT to be in 
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a combat configuration prior to leaving its air or sea embarkation point. Upon 
arrival in an area of operations, the Army wanted the IBCT prepared for 
immediate combat operations. 

The Army planned for each of the pieces and parts of the IBCT to operate 
together for a holistic capability with a focus on the company level. For the user 
community, this point is essential because the IBCT is a system-of-systems. 
Although each of the systems can operate individually, when combined they 
have a decisive effect through their constellation of capabilities. The ORD 
discusses the six Key Performance Parameters (KPPs) that serve as the 
performance drivers for the IBCT. KPPs are: 

Those attributes or characteristics of a system that are considered 

critical or essential to the development of an effective military 

capability and those attributes that make a significant contribution 

to the characteristics of the future joint force as defined in the 

Capstone Concept for Joint Operations (Chairman of the Joint 

Chief of Staff, 2007a, May 1, p. GL-14). 

These KPPs provide metrics in terms of threshold and objective values. The 
Acquisition Strategy Report for the Interim Armored Vehicle listed four KPPs: 
e Interoperability—possesses an interoperable capability to host and 
integrate existing and planned C4ISR systems. 
e C-130 transportability—be transportable in a C-130 aircraft. 
e Infantry/Engineer Squad—be capable of transporting and 
protecting a 9-man infantry or engineer squad. 
e Mobile Gun System Bunker Buster—serves primarily as a bunker 
buster, not as an anti-tank platform. (PM BCT, 2000, p. 14) 


The Army developed the Interim Force KPPs as the critical requirements for a 
family of vehicles that complement one another. The family of vehicles includes 
ten variants, and the IBCT requires each of these variants to achieve its full 
capability (see Figure 3). 
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Interim Armored Vehicle Variants 
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Figure 3. Interim Armored Vehicle Variants (From McCarroll, original 
chart modified, 2008, slide 4) 





F. IAV ACQUISITION STRATEGY 


In accordance with DoD Instruction 5000.2, all acquisition programs 
require an approved acquisition strategy upon program initiation (DAU, 2008, p. 
2.3). The acquisition strategy uses a total systems approach that takes into 
account all activities that will occur throughout the program’s lifecycle (DAU, 
2008, p. 2.3). The program manager is responsible for preparing the acquisition 
strategy and tailoring it to the program’s specific needs and constraints. 
Additionally, the acquisition strategy serves as a decision aid by 

prioritizing and integrating many diverse functional requirements, 

evaluating and selecting important issue alternatives, identifying the 

opportunities and times for critical decisions, and providing a 


coordinated approach to the economical and effective achievement 
of program objectives. (DAU, 2003, p. 1-4) 
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The Army adopted an IAV acquisition strategy that fully supported General 
Shinseki’s charter for a rapidly fielded medium force that could provide strategic 
responsiveness. In accordance with General Shinseki’s guidance for the Interim 
Force, the ORD states that: 

The initial IBCTs will be populated with systems consisting of 

integrated off-the-shelf capabilities. Combined with these off-the- 

shelf systems, innovative applications will enable full operational 

capabilities for the interim force. (Federation of American Scientists, 

2000) 

The IAV acquisition strategy was unique in that it covered both 
developmental and non-developmental efforts. For programs that involve 
development, a technology development acquisition strategy is normally used. In 
accordance with the Defense Acquisition Guidebook, the technology 
development acquisition strategy discusses the management of research and 
development, the number of prototypes, the use of the prototypes in testing, and 
specific decision points for the user and materiel developer to determine the 
maturity of a system under development (DAU, 2008, p. 2.3). 


1. Evolutionary Approach 


The Army used an acquisition strategy that required the use of NDI to 
allow for rapid fielding while avoiding any type of long system development. 
Additionally, the acquisition strategy attempted to execute activities such as 
“development, production, testing, fielding, deployment, and sustainment” in a 
concurrent rather than sequential manner (PM SBCT, 2006, March, p. 1). The 
IAV acquisition strategy adopted an evolutionary acquisition approach. The DoD 
5000.2, The Operation of the Defense Acquisition System defines evolutionary 
acquisition as: 

the preferred DoD strategy for rapid acquisition of mature 

technology for the user. An evolutionary approach delivers 

capability in increments, recognizing, up front, the need for future 
capability improvements. The objective is to balance needs and 


available capability with resources, and to put capability into the 
hands of the user quickly. The success of the strategy depends on 
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consistent and continuous definition of requirements, and the 
maturation of technologies that lead to disciplined development and 
production of systems that provide increasing capability towards a 
materiel concept. (Under Secretary of Defense (AT&L), 2003b, p. 4) 


The evolutionary approach aimed to provide continuous, preplanned 


improvements to meet current and future capability gaps as technology matured 
(DAU, 2008, p. 2.3.2). The Acquisition Strategy Report for the Interim Armored 


Vehicle stated the following objectives: 


Emphasize rapid acquisition, 

Incorporate time-phased requirements as appropriate, 

Integrated acquisition and logistics, 

Stress interoperability of the IAVs within and outside the BCT, 
Incorporate Cost as an Independent Variable (CAIV), 

Integrate test and evaluation throughout the process rather than as a 
final exam, 

Focus on better performance with lower costs and not just on lower 
costs, 

Stress that system performance should also consider better reliability 
and quality, and 

Investigate and incorporate technology as appropriate throughout the 
lifecycle. (PM BCT, 2000, pp. 10-11) 


The program initially used the March 1996, DoD-Instruction-5000.2R 
acquisition structure with a Milestone | to Ill; PM SBCT kept this structure for the 
MGS and NBCRV until those programs reached their Milestone Ill (PM SBCT, 
2006, March, p. 5) (see Figure 4). 
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Figure 4. DoD Program Lifecycle Models (From PM SBCT, 2006, March, 
p. 6) 


2: Risk Management 


The Defense Acquisition Guidebook defines risk management as “the 
overarching process that encompasses identification, analysis, mitigation 
planning, mitigation plan implementation, and tracking” (DAU, 2008, p. 4.2.3.5). 
Additionally, risk management is most effective when the program manager 
integrates it with a program’s systems engineering process “as a driver and a 
dependency on those processes for root cause and consequence management” 
(DAU, 2008, p. 4.2.3.5). The IAV acquisition strategy highlighted four areas of 
risk for the program. 

For schedule risk, the acquisition strategy discussed the high probability 
for “development, test, and production lead times for the MGS” with an initial 
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assessment of red (PM BCT, 2000, p. 23). The program manager’s mitigation 
plan for the MGS development risk was to substitute suitable in lieu of systems 
until the MGS was available (PM BCT, 2000, p. 23). 

For technical risk, the acquisition strategy discussed the potential 
integration issues for the ICV variants with a low probability of occurrence (PM 
BCT, 2000, p. 24). With regard to the ICV, the PM accepted the technical risk. 


G. THE MATERIEL SOLUTION FOR THE IBCT 


Market research began in earnest with the Platform Performance 
Demonstration (PPD) held at Fort Knox, Kentucky from December 1999 to 
January 2000. During the PPD, the Army hosted 35 candidate platforms from 11 
different contractors (Steele, 2000, March, p. 24). The purpose of the PPD was 
to “determine the potential availability of a family or families of systems to equip a 
new brigade organization designed for full spectrum operations” (Bell, November 
18, p. 1). 

The PPD served as a market survey for the Army, not as a competition. 
Given the NDI acquisition strategy, the PPD also provided insights on the 
development of the Operational & Organizational Concept and the overarching 
requirements document. The Army also used it to “evaluate existing systems to 
determine the state of the art, and see if the performance envisioned for the 
interim brigades was achievable” (PM BCT, 2000, p. 5). At the close of the PPD, 
the Army provided each contractor with a written report of their vehicle’s potential 
problem areas (Bell, November 18, p. 3). During the PPD, Major General B.B. 
Bell, the Armor Center’s commanding general at the time, clarified that the PPD 
was not part of the formal competitive process and that the Army was open to 
both wheeled and tracked drivetrains (Steele, 2000, March, p. 24). 

During the PPD, several companies marketed their designs for the MGS 
requirement for the IBCT. United Defense marketed its M-8 Armored Gun 
System, a tracked vehicle that it developed in the early 1990s to meet an 
armored reconnaissance vehicle requirement for the 82° Airborne Division. 


Despite meeting the C-130 transportability requirement and being production 
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ready, the Army cancelled the M-8 program in 1996 because of budget 
constraints (Jane’s Light Armored Vehicles, 2008, August 13). General 
Dynamics Land Systems (GDLS) marketed their Light Armored Vehicle (LAV) III 
with a turreted 105mm gun that it had previously used as a demonstrator for 
international markets (LTG (Ret) Joseph Yakovac, personal communication, 
December 17, 2008). The GDLS variant demonstrated strong potential, but it did 
not have an auto-loader, an integrated C4ISR suite, a coaxial machine gun or 
commander’s weapon, and fire control modifications to integrate the main gun 
ammunition (Gourley, 2003, May). All of those components were essential to 
meet ORD requirements for the MGS. 

The PPD was a critical event for developing Non-Developmental Item 
(NDI) assumptions. The Army assumed that the NDI vehicles could achieve “the 
system requirements with minimal or no modification” based on the PPD 
observations (PM BCT, 2000, p. 18). Soon after the PPD, the Army published a 
Request for Proposal (RFP) on February 29, 2000, and it began a review of the 
contractor’s platforms. The Source Selection Authority (SSA) for the IAV contract 
was Lieutenant General Paul J. Kern. The SSA served as the “sole authority 
designated to direct the selection process and make the selection decision” 
(Kern, 2000, p. 5). 


1. Contract Award (November 2000) 


Three months behind their original schedule, the Army announced on 
November 16, 2000, that the General Dynamics Land Systems & General Motors 
Limited Liability Corporation (GM/GDLS) won the contract award of the ACAT ID 
IAV vehicle (Hinton, 2001, p. 13). Seven defense contractors had submitted 
proposals with two contractors, GM/GDLS and UDLP, submitting several 
proposals. The proposals were evaluated based on five criteria in order of 
importance: 1 & 2) schedule and performance (equal), 3 & 4) supportability and 
cost (equal), and 5) management (Gamboa, 2001, April 9, p. 4). Within the 
performance area, the Army evaluated a performance requirements element and 


a commonality element; within the supportability area, the Army evaluated a 
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deployability element, a sustainment cost element, a system maintainability 
element, and a predicted reliability element (Kern, 2000, p. 9). Although there 
were a number of individual variants that had superior performance, the Army’s 
desire for commonality took priority. Additionally, commonality took priority over 
other suitability factors such as reliability. 

At the contract award announcement, LTG Kern emphasized that he 
selected General Dynamics primarily because of the performance, supportability, 
and commonality that it offered across its ten variants (Gamboa, 2001, April 9, p. 
7). This was particularly important to the Army because it decreased the IBCT 
sustainment and training requirements. Additionally, the Army emphasized the 
GDLS advantages in protection, vehicle speed, and sustainment cost. 

The GM/GDLS based their materiel solution on the Light Armored Vehicle 
(LAV) Ill, an 8 x 8, wheeled, armored vehicle. GM/GDLS centered all ten 
versions of the IAV on the LAV Ill design, and each had unique mission 
equipment packages. The LAV Ill offered a common armored hull, suspension, 
power pack, drivetrain and associated system (GDLS, 2002, p. 5). 

Although the MGS shared the basic chassis as the other nine versions, 
the Army considered it a separate variant because it required additional 
developmental work. During the award press conference in November 2000, 
LTG Kern stated that the “MGS will take the longest [to develop] as it is closest to 
a full development” (Federal News Service, 2000). The Army initially estimated 
that the MGS would require approximately two years of developmental work, 
based on the GM/GDLS proposal. The Army acknowledged that MGS would 
require integration efforts, but it underplayed this by stating that it did not entail 
“new guns, sights, or sensor packages for this equipment” (Federal News 
Service, 2000). The Army considered an extended developmental program, 
defined as greater than 24 months, as counter to the Army’s Transformation 
strategy and early fielding of Interim Brigade Combat Teams. Consequently, the 
Army urged each of the offerors to consider carefully the “probability of success” 
for meeting the 24-month timeline with their variant proposals (Kern, 2000, p. 12). 
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In this regard, LTG Kern acknowledged that the GDLS MGS schedule was 
“substantially inferior” to that of the UDLP variant, but he did not view this as 
unacceptable (Gamboa, 2001, April 9, p. 7). 

At the close of the contract award announcement, LTG Kern also stated 
that there was heavy pressure from higher authority to push for a shorter 
schedule to enable a full operational capability for the Interim Brigade Combat 
Team. He said: 

you talk to all of our military's bosses in the Army, General 

Shinseki, [they say that] we’re too slow. This has been a 

remarkable trip for all of us, to go from a concept about a year ago. 

From their perspective [they say], “we [materiel developers] aren't 

moving fast enough,” rather than “why didn’t we wait.” We have a 

capability, which we are trying to get to the field as quickly as 


possible because it does not exist today. (Federal News Service, 
2000) 


Although the tracked option proposed by United Defense offered an option that 
required little developmental work and a faster schedule at a lower cost, the 
Army made a trade-off based on the limited amount of available information from 
the PPD and the contractor proposals. 

It seems apparent that the Army intended to make the best decision that it 
could with the limited time and information available rather than make a perfect 
decision. Given the information available from the PPD and other market 
research conducted by the materiel developer and user communities, the 
perception was that the GDLS variants, particularly the MGS, could quickly 
mature. It is also interesting to note that within the Acquisition Strategy Report 
for the Interim Armored Vehicle, published in March 2000, the Army identified the 
integration of mission equipment on the ICV as the primary technical risk area 
(PM BCT, 2000, p. 24). Yet this report did not discuss the technical risk of 
integrating the more complex components on the MGS or NBCRYV, both of which 
encountered significant challenges with systems integration (PM BCT, 2000, p. 
24). 
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2. Award Protest 

Soon after the contract award, United Defense, the unsuccessful offeror of 
the M-113 ICV variant and the M-8 AGS variant, filed a protest. The General 
Accounting Office upheld the decision to award the contract to GM/GDLS, and it 
found that the Army’s selection of the GM/GDLS ICV and MGS was reasonable 
(Gamboa, 2001, April 9, p. 7). Within the UDLP award protest, there was 
considerable discussion on system reliability—a_ significant problem later 
encountered with the GDLS MGS. However, the focus of the reliability debate 
centered on the vehicle chassis, not the unique Mission Equipment Packages 
(MEP). It is noteworthy that the GDLS MGS was viewed as having significantly 
superior predicted reliability over the UDLP MGS, mainly because the metric for 
comparison was Mean Miles Between Critical Failures (MMBCF). The use of this 
metric did not truly address the uncertainty of the unproven Aries ammunition 
handling system (AHS) that the GDLS MGS employed. 

The award protest delayed what was already a highly compressed schedule 
by 126 days, and it slowed the program’s momentum (Michael Viggato, Deputy PEO 
GCS, personal communication, December 12, 2008). The Army eventually initiated 
work on the GM/GDLS contract on April 9, 2001 (Hinton, 2001, p. 13). 


H. CONCLUSION 

Despite the protest, the Army successfully initiated the first stage of General 
Shinseki’s plan for Army Transformation. Less than 12 months after General 
Shinseki announced his vision, the Army conducted a series of difficult tasks that 
included the IAV requirements document, PPD & market research, RFP, and source 
selection. While not a perfect process, the view was that the Army could make 
necessary adjustments as necessary rather than seek an optimal solution at the 
expense of time. 

The Army demonstrated a willingness to accept some development on the 
GDLS version of the MGS because of the advantages it offered in commonality 
and performance. The Army perceived that the GDLS variant of the MGS was 


close to ready and it was eager to initiate the program. 
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IV. THE DEVELOPMENT OF THE MOBILE GUN SYSTEM 


A. INTRODUCTION 


As one of the Army’s top acquisition priorities, the Stryker had the full 
support of the Army’s senior leadership as well as dedicated fiscal resources, but 
it also faced the pressures of a time-based acquisition strategy. Unlike other 
programs, the Stryker consisted of both developmental and non-developmental 
variants that were under the same acquisition strategy. 

The Army immediately fielded eight of the Stryker’s variants, while two 
variants required additional development (MGS and NBCRV). The Army knew 
that these platforms required the integration of multiple components, and they 
were operating under the assumption that the MGS would require approximately 
two years to field (Federal News Service, 2000). At the time of the contract 
award announcement, this meant that the MGS would complete its development 
in July 2003. 

Coincidentally, this was the same time that the Stryker’s “product 
champion,” General Eric Shinseki, would end his four-year tenure as the Army’s 
Chief of Staff. Although this two-year estimate proved to be unachievable, it 
provided a sense of urgency to the program. The Army continued to push for the 
rapid development of the MGS because it deemed the MGS as “critical” to 
meeting the expectations of the combatant commanders (Schuster, 2002, May, 
p. 19). 

As one of the two developmental variants, the MGS encountered a series 
of unique challenges; this chapter provides an overview of the MGS 
development. The chapter discusses the MGS EMD contract, its characteristics, 


system requirements, and development events leading up to 2008. 
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B. MGS ENGINEERING, MANUFACTURING, AND DEVELOPMENT (EMD) 
CONTRACT 


The Army selected the GDLS MGS model primarily because of its 
advantages in commonality and performance, with commonality being the 
“overriding factor” (Gamboa, 2001, April 9, p. 7). However, during the source- 
selection process, the Source Selection Case Authority (SSA) believed that the 
GDLS MGS model presented some schedule risk. In fact, the SSA understood 
that GDLS “understated” their schedule and that the schedule was “inconsistent 
with the fundamental terms of the solicitation” (Gamboa, 2001, April 9, p. 7). 

In reference to the RFP, the government clearly stated that the program’s 
objectives may be achieved through “the acquisition of off-the-shelf, non- 
developmental items with integration of components, traditional development, 
[and] systems integration [...] staggered over time and across variants” 
(Gamboa, 2001, April 9, p. 7). However, the RFP stipulated that the Army 
understood that such an effort should stay within the intent of fielding a system in 
a timely manner. 

[The Government] does not anticipate a lengthy development 

program and considers extensive development of solutions to be 

counter to the thrust of this acquisition due to the time, cost and risk 

associated with such an approach. (Gamboa, 2001, April 9, p. 7) 

The Army awarded GDLS with a cost-reimbursement contract for EMD 
that included eight preproduction vehicles for Production Qualification Testing 
(PQT). The EMD contract used performance-based specifications, and it did not 
call out the use of a systems engineering process in the statement of work 
(SOW) (N. Jenny Chang, Tank & Automotive Command Reliability Engineer, 
personal communication, March 3, 2009). At this point, the government was 
unable to use any military specifications or standards unless the Milestone 
Decision Authority (MDA) approved a waiver. Additionally, the MGS did not 
contain a “design-in” approach for reliability as a requirement in the contract, and 
this ensured the use of a “test-in” approach during EMD (N. Jenny Chang, Tank 
& Automotive Command Reliability Engineer, personal communication, March 3, 
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2009). The EMD contract did not require GDLS to conduct any contractor testing 
prior to delivery to the government due to time constraints and because Program 
Executive Office Ground Combat System (PEO GCS) believed that the MGS was 
close to ready (Michael Viggato, Deputy PEO GCS, personal communication, 
December 12, 2008). The abbreviated development period necessitated the use 
of concurrent contractor and government testing with the hope that the vehicles 
would fare well (Kim McCormick, GDLS PM MGS, personal communication, 
January 22, 2009). 


C. MGS CHARACTERISTICS AND REQUIREMENTS 


The MGS retained the same common armored hull, suspension, power 
pack, and drivetrain as the ICV variant of the Stryker. Fully combat loaded 
(without any additional armor), the MGS weighs approximately 47,500 pounds, 
and a three-man crew consisting of a vehicle commander, gunner, and driver 
operate the vehicle (GDLS, 2002, p. 7) (see Figure 5). 


105mm Main Gun High Hard Steet Staucture 
Commander's Weagon (50 Cal Protection 14 Gem 
7 62mm Coax Machne Gun , RPG wiadd on armor 
Spall Liners 

Smoke Grenade Lauschers 


Mobility 

Top Speed — 60 mph 

50m Desh —9 sec 

Wreel Clearance — 21 in 
Vertical Climb — 23 in 

Gap Crossing - 78 in 

Range - 330 miles (Cbt Ops) 


Key Characteristics 


Configuration: Combat (inches; Shipping (inches) Automatic Ammunition Hancling System 
Height: 130.44 105.67 18 105mm Main Gun Rounds-6 Rnds per mnute 
Width: 116.34 104 47 Ammunition Types: 
Length: 300 53 300.53 - HEP (High Explosive Plastic) 
- HEAT (High Explosive Anti Tank) 

Direct Fire Support against hardened targets (walls, ~ KE (Kinetic Energy) 

bunkers, bulidings) - Cannisizr (Anti Personnel) 
Crew: 3 





Figure 5. Mobile Gun System Characteristics (From McCarroll, 2008, 
slide 37) 
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A Caterpillar 3126A-HEUI diesel engine that uses an Allison MD 3066 
automatic transmission powers the MGS, and it has the option of operating in 
either the 8 x 4 or the 8 x 8 mode. The MGS integrates a Low Profile Turret that 
houses a similar 105mm main gun, the M-68A2, as the early version of the M-1 
tank. The secondary armament consists of a coaxially mounted 7.62mm 
machine gun and a commander's M-2 .50 caliber machine gun (see Figure 6). 





Figure 6. Exterior View of the Stryker Mobile Gun System (From GDLS, 
2002, p. 8) 


The remainder of this section describes the MGS role within the SBCT; it 
also describes the system requirements in terms of firepower, survivability, and 
the command, control, communications, intelligence, surveillance, and 


reconnaissance (C4ISR). 


1. MGS Requirements 


Prior to General Shinseki’s announcement in 1999 of his vision for the 
Interim Force, the Army’s user community began work on a requirements 
document for a medium-force. The user community used the insights from the 
PPD to refine their requirements, and it completed the IAV ORD in March 2000 
(PM SBCT, 2008, slide 6). The user community also updated the Stryker ORD 
as part of the Stryker Milestone B, and it went for approval by the Joint 
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Requirements Oversight Council (JROC) in February 2004 (Andrews, 2004, slide 
13). The JROC has a significant oversight role in the Joint Capabilities 
Integration and Development System (JCIDS). 

The JROC encourages collaboration between the services, ensures that 
the services develop capabilities in the joint warfighting paradigm, reviews the 
requirements of programs that may have a joint interest or impact, and validates 
Key Performance Parameters (KPPs) (CUCS, 2007a, May, p. 2). As of 2008, 
the Stryker Capabilities Development Document (CDD) was expected to receive 
JROC approval in 2009 (Fahey, 2008, slide 42). The CDD identifies operational 
performance attributes of the proposed system or increment KPPs and it is a 
required document for a program’s Milestone B review (CJCS, 2007b, May, p. B- 
1). 

Originally, the Stryker’s user proponent, the Training and Doctrine 
Command (TRADOC) System Manager (TSM), was located at Fort Monroe, 
Virginia, and it served as the coordinating organization for the Stryker’s 
requirements. In 2002, the Army transferred the user proponent to Fort Benning, 
Georgia, the home of the Army’s Infantry Center, and it became known as TSM 
SBCT. In 2007, the Army re-designated TSM SBCT as a TRADOC Capability 
Manager (TCM) and it was renamed TCM SBCT. Each of the Army’s branch 
proponents provides input to TCM SBCT on the Stryker’s Mission Equipment 
Packages (MEPs). The Armor Center, located at Fort Knox, Kentucky, provided 
input for the MGS MEP. 


2. The Role of the MGS within the SBCT 


The MGS provides a medium-infantry support capability to the SBCT 
Combined Arms Company, and it complements the nine other Stryker variants. 
The ORD describes the critical nature of the MGS: 


The MGS is essential in setting and maintaining the tactical 
conditions for this collective overmatch by providing the capability 
to rapidly and in succession engage and destroy a diversity of 
stationary and mobile threat personnel, infrastructure, and materiel 
targets. It will have the capability to apply a broad spectrum of 
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munitions with lethal effects under all weather and_ visibility 
conditions. (Federation of American Scientists, 2000) 


The MGS Annex of the ORD states that the “principal function of the MGS is to 
provide rapid and lethal direct fires to support assaulting infantry” (Federation of 


American Scientists, 2000). 
3. Firepower 


The primary requirement of the MGS is to provide the infantry with 
supporting fires (also a KPP), particularly with destroying enemy bunkers and 
sniper positions. With its 105mm main gun, the MGS is required to defeat a 
threat infantry squad at a minimum distance of 50 meters and at a maximum 
distance of 500 meters. The MGS also has to deliver this lethal fire with 
precision against fighting positions in buildings and light structures. Although it 
was required to destroy a variety of vehicles ranging from light-skin trucks to T-62 
tanks, the ORD stipulated this be for self-defense only. The main gun can 
depress to -5 degrees, elevate to +15 degrees over the front of the vehicle, and 
+9 degrees over the rear of the vehicle (Federation of American Scientists, 
2000). The turret and main gun is powered with an electric drive system similar 
to that of the Bradley Fighting Vehicle with both stabilized and non-stabilized 
modes as well as a manual back-up (Federation of American Scientists, 2000). 

The MGS has an M-240C 7.62mm coaxially mounted machine gun on the 
left side of the main gun that can accurately engage threat troops at a maximum 
effective range of 900 meters. The M-240C elevates and depresses with the 
main gun and, therefore, has the same elevation and depression requirements 
as the main gun. Both the commander and gunner control the main gun and 
coaxially mounted machine gun. The MGS also stores 18 main gun rounds with 
all 18 in a ready configuration (Gary Gerlach, Project Engineer, PEO GCS, 
personal communication, January 20, 2009). 

The fire control system supporting the main gun and coaxial machine gun 
provides day and night engagement capability in all types of weather. The 
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Compact Modular Sight (CMS) provides a forward-looking infrared sight (FLIR), 
eye-safe laser range finder (ELRF), and direct view optics (Gary Gerlach, Project 


Engineer, PEO GCS, personal communication, January 20, 2009). 
4. Survivability 


The crew of the MGS has the same level of protection and survivability as 
the ICV variants. The base armor of the Stryker is required to provide 360- 
degree protection against 7.62mm fire and 14.5mm protection with additional 
armor protection. 

The initial requirements for the MGS did not stipulate the use of armor 
protection for the main gun or coaxial machine, although it did require full 
protection for the crew inside of the turret. To protect the three-man crew from a 
secondary explosion of the main gun’s ammunition, the MGS stores the main 
gun ammunition separately from the crew (TRADOC, 2008, p. 19). 


5. C4ISR 


The C4ISR requirements on the MGS are similar to those on the ICV 
variants. As part of the SBCT, the MGS can rapidly share, understand, and 
network information to achieve a common operating picture (TRADOC, 2008, p. 
6). The networking capability of the Stryker allows the SBCT to span a larger 
area than Legacy formations and to respond in a rapid manner to changes in the 
operating environment. 

The networking capability is particularly important to the MGS. The ability 
of the MGS to receive information from other Stryker platforms and infantrymen 
allows it to provide long-range, precision firepower. The MGS also has the same 
level of interoperability with current C4ISR suites as the ICV variants. The 
C4ISR system consists of the following: 

e Intercom System, 

e Radio System, 

e Force XXI Battle Command, Brigade and Below (FBCB2) System, 
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e Ethernet Hub, 

e Ground Positioning System, 

e Driver’s Vision Enhancer (DVE), 

e Training Aids Devices Simulators and Simulations (TADSS), and 
e Embedded Training Computer (ETC). (GDLS, 2002, p. 14) 


The radio system consists of two Single Channel Ground Air Radio 
Systems (SINCGARS) radios (long range and short range) and an EPLRS radio. 
The FBCB2 system communicates through the EPLRS and the GPS provides 
the FBCB2 with positional data (GDLS, 2002, p. 14). 


D. MGS DEVELOPMENT 


As of June 2009, the MGS was nearing the end of its developmental 
period. For the purpose of this case study, one can view its development in four 
overlapping stages. Chronologically, these stages are selection, protest and 
prototype development (2000-2002), early testing (2003), reliability growth 
(2004—2006), and deployment and the path to full-rate production (Fall 2006— 
2009). The focus of the case study is on the reliability growth period from 2004— 
2006; however, a clear understanding of the events leading up to this period is 
essential. 

The early stages of the MGS followed a turbulent cycle of development 
until the MGS PMO instituted the use of systems engineering methodology to 
integrate all of the program’s activities. Prior to the implementation of the 
systems engineering approach, the program experienced a_ turbulent 
development period. The Army deployed the MGS to Operation Iraqi Freedom in 
2007 where it received positive feedback from soldiers (Censer, 2008, April 15). 


1. Stage 1-Selection, Protest, and Prototype Development (2000- 
2002) 


During the November 2000 Stryker Defense Acquisition Board (DAB) 


meeting, the Defense Acquisition Executive (DAE) required successful 
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completion of six exit criteria for the MGS prior to its entrance into Low-rate Initial 
Production (LRIP) (PM SBCT, 2008, slide 34) (see Figure 7). 


MGS Engineering & Manufacturing Development 
(EMD) Phase Exit Criteria 
IAV Acquisiton Decision Memorandum (16 NOV 00 


Interoperability Demonstrate Successful Integration of FBCB2 
Mobility Demonstrate sustained hard surface road speeds 
of 40 mph 


System Reliability (Less GFE) Demonstrate position on a reliability growth curve 
to meet an 60% confidence of achieving 1000 
MMBCF 


Supportability Demonstrate the ability to selfrecover 


Mission Equipment Package Demonstrate successful operation of an integrated 
(Lethality) cannon system to defeat reinforced concrete wall 
with S rounds 


Average Unit Procurement Cost AUPC less than or equalto Objective - 
(AUPC)-MGS $4.7M(TY $4. 2M(BY) 
Threshold -$5.4M(TY /$4.8M(BY) 





Figure 7. EMD Exit Criteria (From PM SBCT, 2008, slide 34) 


Soon after the start of work for the contract in April 2001, GDLS initiated 
the production of the eight preproduction MGS models. In July 2002, the MGS 
PMO believed that the program required 27 months of development prior to Low- 
rate Initial Production (LRIP) in June 2003 (Hsu, 2002, July 22). The initial LRIP 
was 2002, but the program manager moved it to 2003 based on the award 
protest. 

The development of the eight preproduction models took place at the 
General Dynamics Muskegon Technology Center in Michigan. The Muskegon 
Technology Center provided GDLS with the capabilities needed to handcraft 
eight vehicles for Production Qualification Testing (PQT). In March 1996, GDLS 


purchased the Muskegon Technology Center from the Teledyne-Waterpik 
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Corporation; the facility specialized in the development of handcrafted armored 
vehicle prototypes (LTC Shane Fullmer, personal communication, February 27, 
2009). Additionally, Teledyne-Waterpik’s Muskegon technology facility was the 
original designer of the Low Profile Turret (LPT) for the LAV Ill, and it had the 
engineering expertise to develop these vehicles for the Army (LTC Erik Webb, 
personal communication, December 5, 2008). 

However, the processes of the Muskegon facility concentrated on 
handcrafted research and development activities, not on production (Kim 
McCormick, GDLS PM MGS, personal communication, January 22, 2009). The 
engineers at Muskegon had previously worked with the Aries auto-loader portion 
of the ammunition handling system, and, as a result, they were confident that 
they could successfully integrate the replenisher as well. The mindset of the 
engineers at Muskegon was that they could accomplish anything given enough 
time (LTC Shane Fullmer, personal communication, February 27, 2009). 

In July 2002, the Army received its first pre-production model, but PQT 
would not begin until November 2002. The MGS prototypes differed from the 
demonstration version used during the 2000 PPD in that they had: 

e Increased armor protection, 

e An integrated C4ISR suite, 

e An integrated ten-round replenisher, 

e A/7.62mm coaxial machine gun, 

e A .50 caliber commander’s machine gun, 

e A commander's panoramic viewer integrated with the fire control 

system, 

e An eight-round carousel as opposed to a nine-round version, and 

e Fire control modification to integrate all main gun ammunition and 


coaxial machine guns. (Gourley, 2003, May) 


The initial preproduction vehicles received in July 2002 did not contain the 
entire AHS. These vehicles had the auto-loader system but lacked the 


replenisher, which GDLS did not deliver until September. Even then, it took over 
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a month to get the replenisher to line up a round to feed into the auto-loader 
system’s carousel located in the Low Profile Turret (LTC Shane Fullmer, 
personal communication, February 27, 2009). Several individuals in the MGS 
PMO immediately realized that the Aries AHS design would present problems, 
but the extent of these problems was uncertain until the test community verified 
them during PQT (LTC Shane Fullmer, personal communication, February 27, 
2009). The PM planned for the PQT to support a scheduled Low-rate Initial 
Production (LRIP) decision in June 2003. In late 2001, the Army planned to field 
the MGS to the first SBCT in 2005 (see Figure 8). 

The first set of challenges that the MGS PMO anticipated was the 
vehicle’s weight. To meet the C-130 Transportability KPP, the MGS’s PQT 
weight limit was 40,592 pounds, and the initial prototypes were approximately 
43,865 pounds. Although the MGS was overweight by 5,000 pounds, the Army 
continued with the June 2003 LRIP decision because it had a two-stage weight 
reduction program in place to ensure the MGS met the C-130 KPP (Winograd, 
2002, November 25). 
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Integrated Program Schedule Changes (APR 01-JAN 02) 





Program Milestones 


ICV, MC, CV, RV 
MEV, ESV, ATGM 


MGS (APR 01) 


MGS (7 JUN 01) 


MGS (J AN 02) opment Full Production _ 





Figure 8. MGS Program Schedule Adjustments April 2001—January 2002 
(From PM SBCT, 2008, slide 45) 


2. Stage 2—Early Testing (2003) 


The Army began its PQT at Aberdeen Proving Ground in February 2003. 
Soon after PQT began, the Army was disappointed with the mounting problems 
found in the MGS prototypes. The intent of the PQT was to provide system-level 
testing to determine the stability of the design and its readiness for production. 
This meant that the failure modes should have been known and consistent; 
however, new failure modes were frequently appearing (LTC Erik Webb, 
personal communication, March 10, 2009). This indicated that the design was 
unstable and that it needed sub-component testing. First, the MGS showed 50 
problems with human systems integration, known as Manpower and Personnel 
Integration (MANPRINT), and it had to reconfigure much of the C4ISR 
components to allow soldiers to fit and function inside the vehicle. Second, the 
Army noticed a problem with the ammunition handling system (AHS). The AHS 
had difficulty reloading ammunition because of the alignment between the 
replenisher and the carousel (Baumgardner, 2003, May 23). Third, after lowering 
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the 105mm turret five inches to meet the C-130 Transportability KPP, the blast 
overpressure from the main gun muzzle brake was causing a halo effect on the 
front of the vehicle, damaging components mounted to the external hull (Joseph 
Godell, Deputy PM MGS, personal communication, March 6, 2009). 

The engineering effort involved in lowering the turret caused the Army to 
suspend PQT for two months (Joseph Godell, Deputy PM MGS, personal 
communication, January 6, 2009). GDLS determined that the recoil mechanism 
could absorb the additional recoil without any redesign, beyond the elimination of 
the muzzle brake (Joseph Godell, Deputy PM MGS, personal communication, 
January 8, 2009). The PQT began again in July 2003 and the Army completed it 
in November 2003. These engineering issues led to the rescheduling of LRIP to 
February 2004 and then to September 2004. 

Despite the problems encountered during PQT, the Army was satisfied 
with the GDLS fixes to the MANPRINT problems, main gun overpressure and 
recoil, and the AHS. The Army then proceeded to the LRIP decision in 
September 2004. To meet the criteria for LRIP, the MGS had to meet all of its 
Key Performance Parameters (KPPs) to include the C-130 KPP, the vehicle cost 
objective, and a requirement to achieve 1,000 mean miles between system abort 
(half of the requirement of the ICV) (Roosevelt, 2004, August 11). The Army 
defined system abort as any type of significant system failure that occurred on 
the vehicle. Of the six exit criteria, the system abort requirement was the most 
ambiguous because it did not clearly define the minimal reliability requirement for 
the auto-loader system. 

The Defense Acquisition Executive (DAE), Michael Wynne, chaired the 
Defense Acquisition Board (DAB) meeting that determined the LRIP decision. 
The DAB made a determination based on the analysis of the test results from the 
Director of Operational Testing & Evaluation (DOT&E) and the Army Test and 
Evaluation Command (ATEC). The analysis stated that the MGS met the 
requirements for operational effectiveness, but fell short of meeting the minimum 


criteria for operational suitability, mainly because of the MEP reliability (Wynne, 
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2004, p. 1). At the DAB meeting, Wynne expressed substantial concern over the 
reliability of the MGS, but he still approved the limited LRIP of 14 vehicles with 
several caveats. His doubts centered on the ammunition handling system, and 
he required the Army to update the Stryker Systems Engineering Plan (SEP) 
within 90 days (Joseph Godell, Deputy PM MGS, personal communication, 
January 6, 2009). It was at this point that the Army began to adjust its 
expectations for the MGS. Rewriting the SEP would entail a complete review of 
the design and the approach towards improving reliability. 

After the September 2004 DAB meeting, the MGS PMO became acutely 
aware that the development of the MGS would require even more time than was 
expected as well as additional patience (DiMascio, 2004, October 11). As the 
schedule of the MGS continued to slip, elements of the user community 
compounded the technical problems caused by the auto-loader’s reliability when 
they changed the requirements for the armor protection of the MGS (DiMascio, 
2004, October 11). 


3: Stage 3—Reliability Growth (2004-2005) 


While the ICV chassis that the MGS used was highly reliable, the low 
inherent reliability of the Mission Equipment Package (MEP) reduced the overall 
reliability of the MGS. Failure data collected during PQT pointed towards the 
three components that made up the AHS as the major cause for poor MEP 
reliability and, in particular, the AHS replenisher (Joseph Godell, Deputy PM 


MGS, personal communication, January 6, 2009). 


The difference between the actual reliability of less than 20 rounds per 
Operational Mission Scenario/Mission Profile (OMS/MP) cycle and the required 
reliability of at least 90 rounds per mission cycle without a failure was 
significant, and this required tremendous persistence and innovation to remedy 
(LTC Erik Webb, personal communication, May 20, 2009). Both the Army and 
GDLS knew that drastic measures were necessary to increase the overall 
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reliability of the MEP, and this required a costly and extensive reengineering 
effort that led to a change in the schedule (see Figure 9). 


Integrated Program Schedule Comparison (APR 01 and AUG 05) 
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Figure 9. Stryker MGS Program Comparison Schedule (April 2001 and 
August 2005) (From PM SBCT, 2008, slide 49) 


The problems with the auto-loader caused GDLS to abandon its original 
auto-loader design, developed by Aries, and instead use a contractor-initiated 
source selection to choose a new sub-contractor, Western Design, which 
proposed a more reliable design (Joseph Godell, Deputy PM MGS, personal 
communication, January 6, 2009). The MGS PMO employed a Reliability Growth 
Analysis (RGA) methodology based on systems engineering to provide the 
program leadership with the information needed to make decisions on resourcing 
and scheduling (Chang, N.J. & Rohall, D.J., 2008, September, p. 267). The 
MGS PMO encountered the problem of testing for numerical reliability targets 
midway through development, when reliable systems are often the result of the 
early use of systems engineering fundamentals (Defense Science Board, 2008, 
May, p. 5). The use of systems engineering uncovers problems at an early stage 
when the program can incrementally correct them. The case study explores this 
topic in a more detail within Chapter V. 
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While the reliability issues were occurring, the Army’s user community and 
the Director of Operational Testing and Evaluation (DOT&E), under the Office of 
the Secretary of Defense (OSD), made the determination that the MGS PMO 
needed to increase the gun pod’s armor protection based on modeling and 
simulation of future tactical scenarios. The additional capabilities requested by 
the user community and the OSD required additions to the updated MGS TEMP 
as well as further reengineering effort. The increase in armor protection required 
trade-offs in capabilities to ensure that the MGS met the C-130 KPP. The MGS 
PMO now faced the issue of improving the MGS reliability and gun pod 
survivability while concurrently maintaining an acceptable system weight 
(DiMascio, 2005, January 24). 

The new auto-loader contractor, Western Design, replaced the replenisher 
to reduce the complexity of the auto-loading and replenishing mechanisms. The 
Aries replenisher had consisted of two five-round drums, whereas the Western 
Design replenisher consisted of one ten-round drum. After several months of 
intensive RGA effort as part of the test program, the reliability of the system was 
approaching the necessary parameters. Consequently, the new DAE, Ken Krieg, 
approved the final LRIP of 58 vehicles in October 2005 after reviewing the new 
operational suitability test results (DiMascio, 2005, November 14). Although 
reliability growth was not the final development hurdle for the MGS, it opened the 
way for the LRIP decision. 

The use of the RGA and systems engineering process provided the MGS 
Program Office with an objective means of understanding what was occurring 
with the MGS during testing. By 2006, the MGS was exceeding its reliability 
targets. 


4. Stage 4—Deployment and the Path to Full-rate Production 
(2006-2008) 


After production approval for the remaining 58 LRIP vehicles, the MGS 
Program conducted additional Production Verification Testing (PVT), beginning in 


February 2006. The purpose of the PVT was to provide information to support 
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the Milestone Ill decision for Full-rate Production (FRP), scheduled for 2007 
(DiMascio, 2005, December 12). To meet the Milestone IIIl requirements, the 
MGS also had to undergo Live Fire Test and Evaluation (LFT&E) and an Initial 
Operational Test (IOT). 

Although the Army had a Full Rate Production decision scheduled for 
2007, the Iraq Surge diverted the Fort Lewis-based test unit, the 4" Stryker 
Brigade Combat Team of the 2™ Infantry Division, a unit that the Army had 
previously scheduled to support the MGS IOT. The Army subsequently 
rescheduled the Full Rate Production decision for February 2008 after it 
designated another SBCT as the IOT support unit (Joseph Godell, Deputy PM 
MGS, personal communication, January 6, 2009). 

While the MGS still required LFT&E and operational testing, the Chief of 
Staff of the Army, General Peter Schoomaker, determined that the MGS was 
capable of operational deployment with the 4°" SBCT/2™ ID to Iraq. He based 
this decision on the recommendation from the December 2006 Army System 
Acquisition Review Council (ASARC) (Joseph Godell, Deputy PM MGS, personal 
communication, January 8, 2009). Although the Army acknowledged that the 
MGS required “fixes” during its deployment, the vehicle successfully performed 
its mission in theater (Joseph Godell, Deputy PM MGS, personal communication, 
January 8, 2009). 

To resolve these concerns, the MGS PMO and GDLS implemented 
accuracy improvements to the coaxial machine gun, reliability fixes to the 
electronic power components, a better cooling system for the vehicle’s three-man 
crew, and software improvements to the commander’s display unit (Censer, 
2008, May 19). To address these issues, the MGS PMO developed a near-, mid- 
and far-term plan to implement the fixes recommended by the DOT&E to allow 
FRP of the MGS. The Army then conducted a Configuration Steering Board 
(CSB) in October 2008 to review the product manager’s mitigation plan and the 
impacts of implementing the changes on cost and schedule (Roosevelt, 2008, 
August 22, p. 1). The recommended fixes included both requirements shortfalls 
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from the base MGS requirement document, observations from the use of the 
MGS in theater, and DOT&E observations from testing that were not traceable to 
an approved requirements document (COL Robert Schumitz, PM SBCT, 


personal communication, January 29, 2009). 


E. CONCLUSION 


While the MGS program offers a useful case study for lessons learned, 
the developmental challenges encountered were not idiosyncratic to this 
program. The Army has encountered similar problems with complexity in other 
acquisition programs. In fact, a GAO report on the SGT York, an air defense 
weapon system developed in the early 1980s, revealed this: 

One reason for the delay in fielding the (system) was that the 

prototype gun systems the contractors delivered for testing were 

less technically mature than anticipated. This caused testing 

delays and the need for more testing than had been planned. The 

integration of the weapon’s major subsystems and their application 

to a weapon for which they had not been originally designed 


apparently represented a greater technical undertaking than 
originally anticipated. (Conahan, 1986, pp. 4-5) 


Outside of the MGS program, there was tremendous support for the MGS. 
General Peter Schoomaker, the Army’s Chief of Staff after General Shinseki, was 
a “stalwart supporter” of the MGS (DiMascio, 2005, January 24). This chapter 
provided a broad overview of what capability the Army needed from the MGS as 
well as a chronological progression of how it evolved from 2000 to 2008. 

The focus of Chapter V is on the MGS development from 2000-2005, with 
an emphasis on how the MGS program adapted to the complexity of the outer 
environment by analyzing the system’s integration of the ammunition handling 


system. 
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V. MANAGING COMPLEXITY 


A. INTRODUCTION 


A program’s developmental trajectory is seldom smooth, and it typically 
involves overcoming unanticipated challenges. Chapter IV provided a brief 
description of some of the developmental challenges that the MGS encountered. 
In many ways, everything was harder than expected for the MGS, particularly 
with systems integration (COL Robert Schumitz, PM SBCT, personal 
communication, November 25, 2008). The initial momentum of the program and 
the commitment to success by the program’s leadership overcame some of these 
challenges, but the MGS required a change in approach to make it through the 
crisis period of 2004-2005. The crisis occurred because of an inability to meet 
reliability objectives for LRIP, but the root cause of the crisis was an approach 
that did not adequately address the complex environment. To meet the demands 
of the complex environment, the MGS PMO self-organized around a systems 
approach that identified and managed risk. 

The primary area of risk for the program during this period was the low 
level of reliability for the MGS ammunition handling system (AHS). This chapter 
provides an overview of the AHS, the problems experienced with the AHS, the 
systems engineering approach adopted by the MGS PMO and GDLS, and then 
closes with an analysis of the program’s adaptation to the complex environment. 


B. THE AMMUNITION HANDLING SYSTEM 


ae Aries Design 


Early on, GDLS sub-contracted with the Aries Company for a previously 
developed AHS under a fixed-price contract (LTC Shane Fullmer, personal 
communication, February 27, 2009). Aries had an off-the-shelf auto-loader 


available, but it required the development of a replenisher system for the MGS. 
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For the MGS, the AHS consisted of three components: 1) a carousel, 2) a 


rammer, and 3) a replenisher (see Figure 10). 


Replenisher 
Controller 
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Replenisher 


Autoloader Carousel 
Controller 





Figure 10. The Ammunition Handling System (From GDLS, 2005c, slide 3) 


The Aries design used pneumatic power, and it had eight rounds in the 
carousel with ten rounds in two separate 5-round drums. When commanded to 
load a round, the eight-round carousel raised the 12 o'clock position tube 
containing the desired round and the hydraulically actuated rammer picked up 
the round from the carousel, and transferred it to the gun breach, where it 
was loaded (LTC Erik Webb, personal communication, May 20, 2009). To reload 
the carousel, rounds were pneumatically loaded into the carousel located in the 
Low Profile Turret (GDLS, 2005b, slide 3). There were early indications that the 
AHS was problematic. Soon after the delivery of the first pre-production vehicles 
in 2002, the Army noticed that the Aries AHS had difficulty with aligning rounds 


while transferring them from the replenisher to the auto-loader. 
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2. Reliability in Early PQT (2003) 


The requirement for reliability at the start of the program was 1,000 Mean 
Miles Between System Abort (MMBSA) (Chang et al., 2009, March, p. 3). The 
MMBSA measure was based on the performance specifications within the RFP, 
which required the developer to state reliability in terms of “system abort failures” 
(Gamboa, 2001, April 9, p. 17). Furthermore, the RFP required offerors to 
“identify predicted or demonstrated system level reliability for each IAV variant or 
configuration and to discuss failure definition, data sources, and operating 
environment profile showing applicability to the IAVs” (Gamboa, 2001, April 9, p. 
17). As part of the proposal package, the government required each of the 
offerors, GDLS in this case, to assess its own predicted reliability in view of the 
risks associated with integrating highly complex components. Considering the 
performance of the AHS during PQT, it appears that GDLS overestimated the 
reliability of the AHS. 

In 2003, the Army conducted Reliability, Availability, and Maintainability 
(RAM) testing as part of PQT at the Aberdeen Proving Grounds. During this 
testing, the Army required the vehicles to drive 8,000 miles and fire 640 rounds 
with the goal of achieving an 80% confidence level that the production system 
could achieve 1,000 MMBSA (Baumgardner, 2003, July 10, p. 1). The AHS 
failed to achieve the required system-level reliability, and the Army terminated 
PQT approximately two-thirds of the way through the test (Chang et al., 2008, 
September, p. 269). 

The MGS PMO relied on a “test-in” approach for reliability because there 
was not a Design for Reliability (DFR) requirement in the original contract, and 
the compressed timeline made it nearly impossible for GDLS to conduct DFR 
during EMD (N. Jenny Chang Tank & Automotive Command Reliability Engineer, 
personal communication, March 4, 2009). During PQT, the MGS PMO used a 
closed-loop Failure Reporting and Corrective Action System (FRACAS) that did 
not provide an efficient means for reliability growth because of a slow reaction 
time in identifying where failures were occurring in the system. One of the 
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consequences of the slow reaction time was that reliability at the end of the PQT 
was essentially the same as the reliability at the beginning (N. Jenny Chang Tank 
& Automotive Command Reliability Engineer, personal communication, March 4, 
2009). 

Based on these results, a September 2004 Defense Acquisition Board 
(DAB) review required the MGS PMO to improve the reliability of the system prior 
to moving to LRIP. Under the post-DAB testing plan, the DAE required that the 
MGS undergo further RAM tests in FY04 and 1Q/FY05. These RAM tests 
included driving 12,000 miles and firing 1,000 rounds, with the objective of 
achieving the 1,000 MMBSA (DiMascio, 2004, September 13). One outcome of 
the September 2004 DAB was that the MGS PMO and GDLS separated the 
reliability criterion for the MGS MEP from that of the chassis. The measurement 
criterion for reliability originates from two contractual documents created by the 
user, the Operational Mode Summary and Mission Profile (OMS/MP) and the 
Failure Definition and Scoring Criteria (FD/SC) (Chang et al., 2009, March, p. 
154). 

The OMS/MP is an appendix to the system requirements documentation, 
and the purpose of the OMS/MP is to support the development of specifications 
and test plans by describing how a system will operate in different types of 
scenarios (DAU, 2009a). The FD/SC is a jointly developed document between 
the user and the materiel developer that defines system failure definitions during 
reliability testing (DAU, 2009b). Within the Stryker OMS/MP, the MGS performed 
two functions: accumulating miles and firing ammunition. However, the reliability 
criteria was changed because the MGS chassis was the same as the ICV 
variant, which already passed its reliability tests, and the cause of the MGS 
reliability shortfalls centered on the AHS (Chang et al., 2009, March, 154). 

The result of this change was that MGS PMO kept the requirement for the 
MMBSA remained at 1,000 miles, and they re-designated the new MEP reliability 
as Mean Rounds Between System Abort (MRBSA), with a threshold performance 
of 81 MRBSA and an objective performance of 148 MRBSA (Chang et al., 2009, 
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March, p. 154). Soon thereafter, the MGS PMO directed GDLS to abandon the 
Aries design and to find a new design for the AHS as well as a new approach to 
improving the system reliability. 


C. RELIABILITY AS A DESIGN CONSIDERATION DURING THE 

SYSTEMS ENGINEERING PROCESS 

As a requirement, system reliability is an important design consideration 
throughout the systems engineering process, and it plays a critical role in a 
systems lifecycle. According to Blanchard and Fabrycky, 

Every system is developed in response to a customer need to fulfill 

some anticipated function. The effectiveness with which the 

system fulfills this function is the ultimate measure of its utility and 

value to the customer [...]. [S]ystem effectiveness is a composite of 

many factors with reliability being a major contributor. (2006, p. 

285) 
After conducting a functional analysis, the developer constructs a reliability block 
diagram that allocates reliability from a top-down approach. The allocation of 
reliability also serves as an input for Failure Mode Effect and Criticality Analysis 
(FMECA) (Blanchard & Fabrycky, 2006, p. 385). Through the application of a 
systems engineering approach, the materiel developer designs for reliability 
(DFR), aS opposed to testing for reliability (TFR) as an afterthought. Although 
the DFR approach requires sophisticated methodology, it is more cost-effective 
than the TFR approach. As a critical element of a system’s overall performance, 
the developer addresses reliability in all stages of the systems engineering 
lifecycle model (see Figure 11). 
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Figure 11. Systems Engineering Lifecycle Model with Reliability 
Embedded (From Blanchard & Fabrycky, 2006, p. 383) 


According to the Army Materiel Systems Analysis Activity (AMSAA) 
Reliability Growth Guide, the consideration of reliability “is part of the systems 
engineering process,” and systems engineering is merely a means of “viewing 
reliability program activities in an integrated manner” (2000, September, p. 4). 
The different reliability activities include design predictions, apportionment, failure 
modes and effects analysis, and stress analysis (AMSAA, 2000, September, p. 
4). 

In short, reliability growth is a proven method to reduce failures by testing 
an item until failure modes or events occur, identifying the failures, and then 
fixing them. Reliability growth is an iterative design process, with five essential 
elements that include: 1) detection of failure sources, 2) feedback of problems 
identified, 3) redesign effort based on problems identified, 4) fabrication of 
hardware, and 5) verification of redesign effort (see Figure 12). The rate of 
reliability growth hinges on the speed at which these activities occur, the 
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significance of the problems, and the effectiveness of the redesign effort, with 
any of these activities acting as a “bottleneck” to the overall reliability of the 
system (AMSAA, 2000, September, pp. 5-6). 
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Figure 12. Reliability Growth Feedback Model with Hardware (From 
AMSAA, 2000, September, p. 5) 


The key element to achieving a sufficient rate of growth is through 
improvements to a system’s inherent reliability (Chang et al., 2008, September, 
p. 270). Inherent reliability is the element of reliability that materiel developers 
have control over, and it refers to the designed reliability of the system while 
operating under realistic operating conditions. The objective of materiel 
developers is to increase a system’s inherent reliability during the design phase 
and minimize unforeseen problems during system testing. In the case of MGS, 
the Muskegon Technology Center handcrafted the components together, but 
there was not enough time for contractor systems integration testing. In effect, 
the first two years of the MGS development consisted of trial-and-error tests for 


reliability. 


D. PROGRAM ACTIONS 


Based on the failure to pass reliability standards during PQT, the MGS 
PMO initiated a reliability growth plan. After receiving the guidance of the 
September 2004 DAB, the MGS PMO developed a new path forward that 
included a phased plan to address the reliability issues (see Figure 13): 
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e Phase l: Additional Reliability Testing (ART), 

e Phase Il: Systems Engineering Revitalization, Management and 
Process Improvements, and 

e Phase Ill: Redesign of the Ammunition Handling System. (PM SBCT, 
2006, p. 59) 


The MGS PMO also developed a Phase IV plan that emphasized 
survivability improvements to the Low Profile Turret; however, that topic is 


beyond the scope of this case study. 
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Figure 13. Schedule for Phase I-III (From Fuller, 2004a, slide 21) 
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1. Phase |: Additional Reliability Testing (ART) 


Phase | served as a time to regroup and establish a new baseline for the 
program. Prior to ART, GDLS conducted a “contractor shakedown” to ensure 
that the MGS was “mature enough” for the Government’s ART (PM SBCT, 2006, 
p. 59). The overall purpose of Phase | was to demonstrate improvements to 
reliability since the conclusion of PQT and to validate the expectations of 
reliability growth. Phase I, ART, consisted of two elements, pre-ART and ART. 
The MGS PMO and GDLS conducted pre-ART from November 8-18, 2004 and 
ART from December 2004 to June 2005. ART allowed the MGS PMO and GDLS 
to develop and validate the corrective actions for the system-abort modes that 
evaluators identified during the 2003-2004 PQT. 

Phase | also reestablished the MGS baseline, and this served as a 
starting point for the next stage of testing. The actions taken during Phase | also 
allowed the MGS PMO to review and validate the new reliability growth plan 
developed by GDLS (Fuller, 2004a, November 17, slide 5). The MGS PMO 
conditionally accepted the GDLS reliability growth plan, which called for monthly 
updates to MGS stakeholders (Fuller, 2004a, November 17, slide 5). While ART 
occurred, GDLS conducted a parallel effort to select and conduct component- 
level testing on a new design for the AHS. 


2. Phase Il: Systems Engineering Revitalization, Management 
and Process Improvements 


The centerpiece of Phase Il was the use of a systems approach to 
organize the program’s available knowledge and tools. Pragmatically, the MGS 
PMO and GDLS implemented the systems approach through a “revitalized” 
systems engineering plan (PM SBCT, 2006, p. 59). During Phase Il, the MGS 
PMO and GDLS prepared the systems engineering plan for OSD approval in 
January 2005 (Fuller, 2004a, November 17, slide 6). GDLS also dedicated a 
new team of systems engineers to the MGS program for implementation of the 


plan. 
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The new systems engineering plan not only addressed the redesign of the 
AHS, but it also addressed the managerial processes that governed daily 
activities within the program (Chang et al., 2009, March, p. 152). Within GDLS, 
all of the employees assigned to work on the MGS were required to complete a 
course on Whole Systems Architecture and Design Failure Mode and Effects 
Analysis training (Josh King, GDLS Stryker Project Engineer, personal 
communication, 10 March 10, 2009). The training provided the employees, who 
came from a broad range of disciplines, with a common operating picture of how 
GDLS intended to approach reliability growth. The training also ensured that all 
of the project engineers understood how to prioritize failure modes in the design 
(Josh King, GDLS Stryker Project Engineer, personal communication, March 10, 
2009). In a similar manner, PM SBCT established a 40-hour course on systems 
engineering, and it required this training for all key staff members (PM SBCT, 
2006, p. 34). 


a. MGS Integrated Product Teams (IPTs) 


GDLS reassigned their Senior Director of Product Engineering to 
be the Senior Director of MGS Engineering. The Senior Director of MGS 
Engineering assumed central control over all MGS engineering decisions, and he 
reassigned a number of key employees to MGS full-time as Integrated Product 
Team (IPT) leads. The MGS PMO and GDLS required every IPT to have a 
technical manager and a lead systems engineer who had responsibility for “risk 
management, configuration management, technical data management, and to 
control physical and functional interfaces across subsystems” (PM SBCT, 2006, 
p. 42). GDLS assigned each of these IPT Leads to communicate with specific 
government organizations such as the user, materiel developer, and Army 
testers (Josh King, GDLS Project Engineer, personal communication, March 10, 
2009). The Senior Director of MGS Engineering also institutionalized a multi- 
disciplinary IPT meeting structure to improve the flow of information (Josh King, 
GDLS Project Engineer, personal communication, March 10, 2009). 
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In a similar move, the government assigned personnel to each of 
the IPTs, and the MGS PMO reassigned one employee to GDLS on a full-time 
basis, allowing him to participate in daily meetings to enhance the collaboration 
between the government and GDLS (see Figure 14) (LTC Erik Webb, personal 
communication, March 10, 2009). PM SBCT assigned each IPT a charter that 
contained “pre-defined boundaries for decision-making,” and the PM empowered 
all of the IPTs to make decisions at the lowest level possible (PM SBCT, 2006, p. 
32). PM SBCT also established a set of weekly metrics to review issues, and it 
made this information available to everyone in the program by placing it into a 
common database known as the Integrated Data Environment (PM SBCT, 2006, 
p. 34). The MGS IPT metrics measured cost variance, schedule variance, and 
actual versus planned product definition release (PM SBCT, 2006, p. 35). 
Consequently, communications among functional areas and between the 
government and GDLS occurred on a more frequent and consistent basis, 
contributing to a collaborative “team atmosphere” (Josh King, GDLS Project 


Engineer, personal communication, March 10, 2009). 
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Figure 14. MGS IPT Structure (From PM SBCT, 2006, p. 31) 
























































Specific to systems engineering, PM SBCT and GDLS instituted a 
joint Systems Engineering Integration Team (SEIT) with the purpose of 
coordinating all systems engineering activities (PM SBCT, 2006, p. 36). The 

15 


SEIT had access to over 100 systems engineers, and it was “responsible for 
systems engineering technical management, including gate checkpoint reviews, 


problem management, and risk management” (PM SBCT, 2006, p. 36). 


b. Failure Prevention and Review Board and the Design 
Actions and Reporting System 

The MGS PMO and GDLS also instituted a multi-functional team to 
serve on a Failure Prevention and Review Board (FPRB) led by the MGS PMO. 
The FPRB met twice per week, and the MGS PMO used the FPRB to oversee 
the Design Actions Reporting and Tracking System (DART) and all corrective 
actions. The DART played a critical role in that it managed “the discovered failure 
modes as well as associated corrective actions” (Chang et al., 2009, March, p. 
152). 


The DART served as the primary reporting system for the Failure 
Mode Effects and Criticality Analysis (FMECA). With a relatively small sample 
size and a limited amount of time available for testing, the DART allowed for 
highly efficient identification and correction of failure modes (see Figure 15). The 
DART process was highly effective, and it reduced the cycle-time for corrective 
actions on failure analysis from 90 days to 45 days (Fuller, 2004b, December 20, 
slide 8). 
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Figure 15. Design Actions Reporting and Tracking Process (From Chang 
et al., 2009, March, p. 153) 


3. Phase Ill: Redesign of Major Subsystems and Integration 


The purpose of Phase Ill was to “demonstrate reliability growth by 
conducting RGT” and to “redesign essential elements of the AHS” (PM SBCT, 
2006, p. 60). On October 19, 2004, GDLS selected Western Design’s AHS as 
the replacement for the Aries design. The new design had a 50% reduction in 
parts, and it replaced the two 5-round canisters with one 10-round canister in the 
carousel. In the second and third quarters of 2005, GDLS conducted systems 
integration of the Western Design AHS into the MGS (Fuller, 2004b, December 
20, slide 12). During this period, GDLS conducted a Preliminary Design Review 
and a Critical Design Review as part of the reinvigorated systems engineering 
process for the new AHS as well as other design changes for the MGS (Fuller, 
2004b, December 20, slide 13). Soon thereafter, GDLS conducted a short 
“contractor shakeout” test in June to August 2005, with government participation 
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to determine the level of system reliability (Chang et al., 2008, September, p. 
269). The actual reliability during contractor shakeout was 57 MRBSA, short of 
the threshold requirement of 81 (Kim McCormick, GDLS PM MGS, personal 
communication, January 22, 2009). The MGS PMO determined that the 
Production Verification Test (PVT) would need to serve as an additional reliability 
growth test (Kim McCormick, GDLS PM MGS, personal communication, January 
22, 2009). 

PVT began in May 2006 and finished in April 2008 with three production- 
like vehicles (Chang et al., 2009, March, p. 155). The actual reliability growth 
rate significantly exceeded the expected growth rate (88% versus 22%), 
demonstrating the effectiveness of the methodology developed in Phase | and Il. 
The actual reliability during PVT was 104 MRBSA, which exceeded the threshold 
requirement (Kim McCormick, GDLS PM MGS, personal communication, 
January 22, 2009). When viewed in comparison to the 13 MRBSA in PQT, the 
improvement is substantial. It took the crisis of September 2004 to shift the MGS 
program from a series of incremental changes to a dramatic restructuring built 


around the systems approach. 


E. RISK MANAGEMENT PROCESS 


The Stryker acquisition strategy attempted to minimize overall 
programmatic risk by using NDI and “near-NDI” (PM SBCT, 2006, p. 106). As 
part of the March 2000 acquisition strategy, the PM SBCT identified risk on a “top 
level in terms of program cost, schedule, and technical performance to allow 
informed decision-making” (PM SBCT, 2006, p. 106). After the revitalization of 
the systems engineering approach in 2004-2005, PM SBCT integrated risk into 
the systems engineering process with an effort to identify risk from the “bottom 
up” and from “top down perspectives” (PM SBCT, 2006, p. 106). PM SBCT and 
GDLS made use of the information derived from all collaborative groups to 
include the IPTs, the systems engineering risk team, and a risk review board in 
identifying risk and developing integrated solutions. 
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PM SBCT and GDLS initiated a process where they formally discussed 
risk at all program reviews and program milestones. Additionally, PM SBCT and 
GDLS made all risk documentation available to stakeholders on the common IDE 
database (PM SBCT, 2006, p. 107). While PM SBCT was responsible for 
oversight of the risk management process, GDLS served as the primary manager 
for technical risk (PM SBCT, 2006, p. 106). PM SBCT and GDLS not only 
shared risk, but they also used a common risk management process that 
assessed risk on a continuous basis (see Figure 16). The next section examines 


the MGS from the perspective of complexity. 
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106) 


F. COMPLEXITY AND THE MGS 


The literature review in Chapter Il demonstrates that there are common 
properties to complex programs. What makes a program complex is not only the 
internal technical complexity of the system but also the upstream complexity that 
originates from the outer environment. Based on this perspective, the MGS 
certainly qualifies as a complex program. 
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While the people who worked on the MGS program were extremely 
capable and dedicated to the program’s success, the MGS still encountered 
numerous difficulties that resulted from organizational, environmental, and 
technical forces that affected the program. One way to explain the program is by 
describing it in terms of Simon’s model of complexity described in Chapter II. 

The complexity of the outer environment created uncertainty and, in the 
process, increased the MGS program’s overall level of risk. The MGS program, 
representing the inner environment, was in a search to find an approach to 
manage the complexity and uncertainty that it faced. The next section addresses 
the outer and inner environments, and it provides an analysis of how the MGS 


PMO managed complexity. 
1. The Outer Environment 


According to Simon (1981) and Kauffman (1993), all complexity originates 
outside of a system, and, in the case of the MGS, the outer environment 
represents all factors that directly and indirectly had an impact on the MGS. Six 
risk factors stand out in this category including: 1) the strategic uncertainty of the 
post-Cold War era, 2) time-based acquisition strategy, 3) the unintended 
consequences of the acquisition reforms of the 1990s, 4) the common 
developmental and non-developmental acquisition strategy, 5) the categorization 
of MGS as NDI, and 6) the focus on vehicle commonality (see Figure 17). These 
risk factors fall under one of three areas of criticality based upon information 
adequacy: 1) known-known, 2) unknown-known, and 3) unknown-unknown. All 
of these factors are interrelated, but the inexact and unknown causality of this 
relationship is what made the MGS program complex. 
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Figure 17. Simon’s Complexity Model Applied to the MGS 


a. Environmental Risk Factors 


At the center of General Shinseki’s ladder of inference was the 
uncertainty of the new multi-polar world. Unlike the bipolar world, the United 
States could no longer predict with any accuracy the actions of its adversaries. 
The post-Cold War period demonstrated that the United States required the 
flexibility of inserting a medium-size formation anywhere in the world within 96 
hours, with the ability to address a continuum of operations ranging from 
humanitarian aid to major combat. The period from 1990-2008 demonstrated 
that this risk area was clearly positioned in the category of an unknown-unknown. 
Strategic uncertainty drove the Army’s Transformation strategy and the time- 


based acquisition strategy. 


81 


b. Organizational Risk Factors 


General Eric Shinseki, the champion of the Army’s Transformation 
strategy, understood that this strategy was a long-term endeavor, and Stryker 
was merely the first increment of change. Beyond the technological challenges 
of transformation, he soberly determined that the single biggest obstacle to Army 
Transformation was the need to overcome the Army’s own byzantine 
bureaucracy. As the decisive point of the Transformation strategy, he 
determined that Stryker required a time-based, rather than an event-based, 
strategy to achieve “irreversible momentum” (Shinseki, 2003). With a specific 
date for initial operational capability, this risk factor falls under the known-known 


category. 


In retrospect, a two-year development period for a vehicle that 
required extensive systems integration may seem unreasonable; yet when 
viewed from the assumption that the MGS was close to ready and from the 
strategic perspective of General Shinseki, its rationale seems more apparent. 
The March 2000 Acquisition Strategy Report for the Interim Armored Vehicle 
served as the over-arching strategy for the developmental and non- 
developmental IAV variants, but the strategy did not adequately address the 
technical risk associated with the MGS and NBCRY, particularly with integrating 
multiple Non-Developmental Items and Government Furnished Equipment in a 
relatively short time period. The Acquisition Strategy Report for the Interim 
Armored Vehicle stated in several cases that “limited development activity may 
occur,” and this did not take into account the tremendous challenges associated 
with systems integration (PM BCT, 2000, p. 10). 


As an integrative approach for all program activities, the March 
2000 acquisition strategy was overly focused on the eight production models. 
Ultimately, this led the program to leave out critical developmental steps such as 
systems integration in the interest of time. The importance of the systems 
integration process is crucial to risk mitigation because it reveals unpredictable 


82 


interactions between components and validates the technical assumptions. The 
acquisition strategy clearly had a strong relationship to the MGS PMO’s 


assumptions on NDI. 


The unintended consequences of the acquisition reforms initiated 
by Dr. William Perry in the 1990s also affected the MGS. A broad assessment of 
these reforms, particularly the long-term cost savings, is beyond the scope of this 
case study. The DoD intended to improve the effectiveness and reduce the 
cycle-time of defense acquisitions through the use performance-specification 
reforms, but, in the early stages of their execution, they had the potential to 
increase the government's level of risk because of the disengagement from the 
contractor (Yoder, 2004, p. 2). While the emphasis on performance-oriented 
specifications provided the contractor with more latitude for innovation, it also 
created the potential for increased risk if the government did not identify an 
effective verification plan to accompany the performance specifications. The 
difficulty of obtaining waivers contributed to the government's disengagement 
from the contractor because the government had to put increased faith in a well 
thought out verification plan that it stipulated in the EMD contract, and on the 
engineering approach taken by the contractor. The government wrote the MGS 
EMD contract with performance-based requirements and a nearly complete 
absence of military specifications and standards, and the EMD contract did not 
call out specific requirements for component-level reliability testing with a 
systems engineering process (N. Jenny Chang, TACOM Reliability Engineer, 


personal communications, March 4, 2008). 


Cc. Technical Risk Factors 


The outer environment included two technical risk factors that were 
strongly interrelated: 1) the user focus on vehicle commonality and 2) the 
categorization of MGS as NDI. What made the MGS requirement particularly 
challenging was the user emphasis on commonality. Individually, the Army could 
have optimized on performance and reliability by developing separate pieces of 
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equipment; however, the emphasis on commonality was a new concept, 
especially given the competing requirements of transportability and lethality. The 
Army was looking for a common vehicle to perform a wide range of tasks; 
however, the implementation of this concept proved to be a challenge. GDLS 
seemed to provide the optimal solution for the commonality requirement with its 
105mm equipped LAV III that initially appeared to be a non-developmental item. 


General Shinseki’s intent was to field a medium-force capability that 
consisted of off-the-shelf solutions. The emphasis on an off-the-shelf solution 
was a central element of the acquisition reforms of the 1990s described in the 
organizational risk factors. Although the MGS consisted of NDI components 
such as the chassis, C4ISR equipment, the low profile turret, and the Aries AHS, 
GDLS did not have an integrated solution at the time of the contract award. The 
categorization of the MGS as NDI was somewhat misleading because it did 
require significant modification. Although the NDI and commonality assumptions 
caused significant problems during development, both of these assumptions 
were closer to being a known-known rather than an unknown-known. In terms of 
information adequacy, the design of the time-based acquisition strategy caused 
the Army to overemphasize speed. 


2. The Inner Environment 


One can look at the MGS program symbolically as a “box within a box” 
that had to adapt to the risk factors of the dynamic outer environment (Simon, 
1981, p. 148). The MGS PMO worked in an environment of considerable 
uncertainty while facing a time-based acquisition strategy. The objective of the 
inner environment is to achieve a sense of resilience or homeostasis. Through a 
series of self-organizing actions, the MGS PMO attempted to adapt the MGS 
program to the risk factors of the outer environment. 

The new approach consisted of three inseparable elements that enabled 
the MGS program to manage the complex environment: 1) systems approach, 2) 
error-embracing behavior, and 3) collaborative learning. Although the systems 
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approach is the decisive effort, it required the complementary effects of the two 
shaping efforts, error-embracing behavior and collaborative learning. 


3. Systems Approach 


The interdependent variables of the outer environment are difficult to 
separate and analyze as snapshots in time. For this reason, the decisive effort of 
managing complexity is the systems approach. The systems approach attempts 
to view the entire system in a holistic manner while coordinating people and 
processes. The problem of uncertainty becomes more difficult with acquisition 
programs that require the rapid integration of technology in a short time period. 

Initially, the program operated under the assumption that the MGS would 
only require limited development. The MGS program viewed the use of systems 
engineering as either unnecessary or too time-consuming. As it became 
increasingly evident that the program would not meet the initial schedule and 
performance objectives, the use of systems engineering became a necessity. 

Until 2004, the schedule consisted of a series of tests (PQT) that 
disproved all of the flawed assumptions from the beginning of the program. 
Rather than provide the Army with a well-integrated system in 2002, GDLS used 
the “big bang” approach to systems integration by piecing together all of the sub- 
systems at the same time (Hyunh, 2008, slide 20). The systems engineering 
process adopted by the MGS PMO and GDLS revealed that systems integration 
takes time and requires a disciplined process. 

What the MGS PMO clearly understood was that the consequences of 
proceeding down the original trial-and-error approach were clearly not producing 
the desired result. The area in which this approach demonstrated unmistakable 
progress was in reliability growth for the AHS (see Figure 18). 
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Figure 18. Reliability Growth over Time (From GDLS, 2009) 


In the trial-and-error approach, the MGS PMO hoped to achieve success 
during a relatively short PQT; however, this was a nearly impossible expectation. 
The implementation of a systems engineering approach played a major role in 
reducing the program’s overall level of risk; in turn, this strengthened the Defense 
Acquisition Board’s (DAB) confidence in the program (Wynne, 2004, p. 2). In 
complex programs that require personnel from multiple disciplines—such as the 
MGS—the use of systems engineering is critical to address problems from 
multiple perspectives with a holistic perspective. 


4. Collaborative Learning 


When developing a complex system, the effect of social influences, 
particularly collaboration, becomes increasingly important because one of the 
primary issues that arises is the lack of communication and knowledge 
dissemination between stakeholders (Prencipe, Davies, & Hobday, 2005, p. 49). 
The systems engineering process takes social influences into account with its 


emphasis on interdisciplinary collaboration. 
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The organizational adaptations to accommodate the reliability growth plan 
(FPRB and DART) demonstrated the need for organizations to be _ highly 
proficient at monitoring and acting on the rapid flow of information. The 
effectiveness of collaborative learning demonstrates that the free flow of 
information is possible if the program leadership establishes a culture that 


identifies and eliminates defensive barriers. 


One reason that the MGS PMO and GDLS took hold of collaborative 
learning was that the program reached the crisis point. Defensive barriers came 
down, and both the MGS PMO and GDLS saw it as an opportunity to get the 
program on track. In this case, the crisis period of late 2004 served as an 
innovation opportunity for both GDLS and the MGS PMO to establish a new 
learning network (see Figure 19). 
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Figure 19. Example of Collaborative Learning (From GDLS, 2007, slide 5) 
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Additionally, complex programs must deal with information that falls under 
the known-known, unknown-known, and unknown-unknown categories. Risk 
management is practical with known-known and unknown-known information, but 
it is not as effective with unknown-unknown events because these events are 
almost impossible to predict. That is one reason why it is essential for 
organizations to have a collaborative learning capacity that enables them to 
adapt to unpredictable situations. The capability for organizations to adapt to ill- 
structured and unpredictable problems makes collaborative learning a critical and 
complementary effort to the systems approach and to error-embracing behavior. 
The use of the Failure Prevention and Review Board (FPRB) and IPTs 
demonstrated that reduction of cycle-time with the reliability growth is possible 
through a collaborative and disciplined effort. 

Recognizing the importance of social factors in the implementation of 
systems engineering, the MGS PMO and GDLS realigned their organizations in 
late 2004 to improve their level of collaboration and ability to implement the 
systems engineering process. However, the systems approach and collaborative 
learning requires a culture where the program leadership rewards individuals for 


identifying problems and developing integrated solutions. 
5. Systematic Error-embracing Behavior 


An overall strategy that integrates the use of systematic, error-embracing 
behavior with the systems approach and collaborative learning provides a 
complex program with the means of determining how components and sub- 
systems will interact. Initially, the MGS PMO and GDLS development approach 
was to simultaneously bring many components together and hope that the tests 
were successful. As it became more apparent that the design was immature, the 
primary method to reduce the knowledge gap between actual and expected 
performance was to seek error-embracing behavior in the form of identifying and 


correcting failure modes. 
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The MGS PMO developed a path for reliability growth that started with 
pre-ART and concluded with PVT. The MGS PMO applied the lessons learned 
from PQT by going directly to systems-level testing and then conducting a series 
of component-level tests on the new Western Design AHS and other design 
improvements. One reason that the reliability growth was so successful in 2005- 
2006 was the systematic identification of failure modes. The MGS PMO and 
GDLS identified failure modes in a small enough scope to diagnose them and 


develop corrective actions in a methodical manner. 


G. CONCLUSION 


To the outside observer, it may seem as though the Army and GDLS did 
not exercise enough due diligence with the development of the MGS. In 
retrospect, no one is omniscient and individuals have tremendous difficulty in 
making objective comparisons across multiple options while trying to figure out 
the consequences of those decisions (Simon, 1979, September, p. 502). In 
Judgment Under Uncertainty, Tversky and Kahneman also discussed this 
concept when they said, 

People rely on [a] limited number of heuristic principles, which 

reduce the complex tasks of assessing probabilities and predicting 

values to simpler judgmental operations. In general, these 


heuristics are quite useful, but sometimes they lead to severe or 
systematic errors. (1974, September 27, p. 1124) 


A perfect adaptation to the outer environment is nearly impossible for 
many reasons but mainly because the decision-makers, the MGS PMO in this 
case, were operating under uncertainty. To make the best decisions possible, 
the decisionmakers needed as much fact-based information as possible to 
establish their baseline. With the MGS, the Army initiated the program with 
imperfect information based on inaccurate assumptions in the interest of time. 
The future occurrence of a similar situation is preventable if the lessons learned 


are properly absorbed. 
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There is no simple answer to a root-cause analysis on the troubled 
development period of the MGS from 2001-2008. It seems evident that the Army 
and GDLS satisficed in their development strategy to meet the time-to-market 
requirements. Moving beyond the actual system reliability, this case study 
looked at the structure of processes to determine how an overestimation of the 
system reliability occurred. 

In effect, the government made decisions early on about the length of the 
schedule and the test approach that did not reflect the technical status of the 
system, and the government anchored these decisions on_ inaccurate 
assumptions about the MGS. In retrospect, it appears that the Army started off 
with a tendency for unwarranted optimism that the MGS PMO and GDLS could 
field the system on the original schedule. That optimism did not take into 
account the lesson that time-to-market is not free and systems integration takes 
time. The last two chapters demonstrated that a rigorous and well-resourced 
systems engineering process is the most effective way to reduce technical risk in 
the face of uncertainty. 

All of this points to the need for organizations to deal with uncertainty, 
particularly within complex systems. Within defense acquisition, the solution to a 
problem is not only dependent upon the objective information provided to the 
decision-maker but also upon the type of process that the decision-maker uses. 
A decision maker must determine what he or she knows about a system and 
must then determine how much information is sufficient, given their availability of 
time and resources. The next chapter addresses the lessons learned from the 
MGS case study on managing complexity. 
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VI. CONCLUSION AND LESSONS LEARNED 


A. INTRODUCTION 


One of the stated goals of the Defense Acquisition System (DAS) is to 
provide users with “effective, affordable, and timely systems” that are developed 
in “response to an approved need” (Under Secretary of Defense (AT&L), 2003a). 
The Army provides program managers with a charter to field these systems given 
cost, schedule and performance constraints while navigating a complex 
environment. The difficulty in fielding systems stems from the complex 
environment found in the defense acquisition system. The environment is 
complex because of the difficulty in determining how the risk factors are 
interrelated. Environments that encounter a greater degree of complexity and 
uncertainty will also experience an increase in their overall level of program risk. 
The MGS case study attempts to document how one program managed that 
complex environment. 

“Manage” is the key term because program managers cannot eliminate 
uncertainty and complexity, but they can manage it, if they have an adequate 
strategy in place. In Embracing Uncertainty, Clampitt and DeKoch (2001) 
describe five methods for creating certainty that include gut instincts, 
experiences, reasoning, and testing (p. 47). Yet, in their analysis, they debunk 
the notion that one can eliminate uncertainty in decision-making (Clampitt and 
DeKoch, 2001, p. 28). In The Fifth Discipline, Senge discusses the misleading 
notion that effective managers must have an omniscient picture of what is 
occurring around them at all times when he said: 

it is simply unacceptable for managers to act as though they do not 

know what is causing a problem[...]Those intent on reaching such 


positions learn early on to develop an air of confident authority. 
(2007, p. 234) 


This case study makes it evident that charting a course of certainty in all 
but the most simple acquisition programs is not possible given the tremendously 
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complex environment faced by today’s program managers. The MGS program 
experienced complexity in terms of organization, environment, and technology. It 
is no surprise that program managers frequently use the cliché “it depends” when 
describing a solution to a problem. The program manager does not base his or 
her response on a scientific analysis of the problem, but, rather, the program 
manager bases the response on years of observing unpredictable interactions 
between complex events. 

Although the pursuit of absolute certainty is a quixotic program objective, a 
more pragmatic objective for program managers is the management of 
complexity. What follows is a restatement of this case study’s research question, 


a discussion of the core findings, and a modest list of lessons learned. 


B. RESEARCH PROBLEM 


The primary research problem was to find a significant developmental 
problem experienced with the MGS and then to analyze the root causes of the 
problem as well as the corrective actions taken by the MGS Product 
Management Office (MGS PMO). Parallel to this effort, this case study explored 
complexity theory to determine if it was applicable to the MGS program. After 
conducting the analysis, this case study attempted to draw insights on how the 
MGS program managed complexity and then to determine what lessons one 
could apply to other acquisition programs. 


C. FINDINGS AND APPLICATION 


1. Findings 


The Army planned to acquire the MGS under an accelerated, time-based 
acquisition strategy. However, the acquisition strategy did not achieve the early 
fielding of the MGS, which was one of the Army’s primary objectives. The 
acquisition strategy is the “high level business and technical management 
approach designed to achieve program objectives within required resource 
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constraints” (DSMC, 1999, 1-1), but the IAV acquisition strategy did not account 
for the technical difficulties encountered in transitioning from the early MGS 
variants to the production version. 

The Army took a number of steps to mitigate program risk to 
accommodate the time-based acquisition strategy. In 1999, the Army conducted 
a Platform Performance Demonstration (PPD) to determine the “state of the art,” 
and it used the information gained from the PPD to refine the requirements and 
develop the Request for Proposal (RFP). The Army also mandated that the MGS 
use NDI components to limit the amount of development required. 

Despite the steps taken to reduce programmatic risk, the MGS still 
required a considerable amount of development. It was not until 2002 that the 
Army realized that there was a gap between the expected or anticipated 
performance of the MGS and its actual performance. The early MGS variants 
were less technically mature than anticipated, and this required additional time 
for development and testing. 

What makes the MGS program interesting as a case study was the rate of 
improvement in the MGS reliability after the strategic approach changed. This 
case study used the MGS reliability problems as a microcosm for analyzing how 
a contemporary acquisition program self-organized to increase its adaptation to 
complexity. During the crisis period of 2004-2005, the MGS PMO adopted a 
systems approach complemented by error-embracing behavior and collaborative 
learning. 

The systems approach adopted by the MGS PMO and GDLS improved 
the capacity of the program to self-organize when the complex environment 
around the program was constantly changing. The MGS PMO realized that the 
technical progress of the vehicle was out of alignment with the acquisition 
strategy, and it took steps to redefine the strategy through the integration of the 
systems approach, error-embracing behavior, and collaborative learning. 

Based on the information available, the case study concluded that 


intensive programmatic crises occurs when an acquisition strategy does not 
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adequately synchronize critical program activities such as risk management, 
systems engineering, test and evaluation, contract management, and integrated 
product/process development. These factors strongly correlate to the success 
factors that are associated with the actions taken by the MGS PMO and GDLS 
(see Figure 20). 
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Figure 20. MGS PMO Strategic Approach 


Programs that embrace a systems approach complemented by error- 
embracing behavior and collaborative learning are capable of accepting greater 
degrees of risk associated with uncertainty and complexity. These concepts are 
not new. In fact, defense acquisition doctrine has a deep and broad array of 
explicit Knowledge available to acquisition programs that discusses these 
concepts, but it is unclear how of much of this doctrine is adhered to. 
Furthermore, it is unclear if lessons learned from other programs such as the 
Army’s Sergeant York air defense system, the Navy’s T-45 flight trainer, and the 
Army’s Armed Reconnaissance Helicopter are fully absorbed by the acquisition 


community. 
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2. A Strategic Approach is Necessary to Manage Complexity 


External and internal complexity results in increased downstream levels of 
uncertainty for acquisition programs. Managing uncertainty is possible through 
continuous strategic planning that ascertains the level of information available 
from the environment and integrates program activities to achieve objectives 
while recognizing resource constraints. Over time, the problems caused by 
complexity will change, and the program manager must make corresponding 
adjustments to the strategy. Between 2000 and 2006, the MGS PMO self- 
organized to improve the alignment and fit of their strategic activities (see Figure 
21). 
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Figure 21. MGS Acquisition Strategy Alignment over Time 


How does a program manager proactively determine the strategic 
approach? It is essential to point out that acquisition strategy is not a static 


program document that the program manager updates at key milestones. Rather 
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acquisition strategy is a continuous process that the program manager uses to 
integrate all elements of his or her program, while recognizing the risk and 
uncertainty in the complex environment. 

The key elements of an acquisition strategy will not align by default. 
Rather, self-organization is an adaptation to complexity that requires significant 
effort and foresight. The program manager should start with the program’s 
internal and external goals, and then align the program’s activities to fit those 
goals. After achieving some alignment, the program manager will need to 
reinforce the fit between elements. Therefore, the program manager must often 
take on the roles of an orchestrator and synchronizer. 


3: Integration of Strategic Activities 


The difference in program outcome could originate from the program 
manager’s ability to develop an acquisition strategy that adapts to the 
environment through the alignment and fit of its strategic activities. The 
acquisition strategy should serve as a means to coordinate the work of all 
individuals who work for or with the program. As a dynamic planning document, 
it should ensure that the program’s activities reinforce one another and are 
consistent. 

With acquisition strategy, the whole matters more than any individual 
activity. At the core of strategic planning for acquisition programs is the 
alignment of these five elements: integrated product/process development, risk 
management systems engineering, test and evaluation, and _ contract 
management. There is no cookie-cutter approach or template for strategy 
implementation because each case is unique. When properly tailored to a 
common strategic vision, these activities become powerful tools to manage 


complexity. 


a. Integrated Product/Process Development (IPPD) 


The use of Integrated Product/Process Development provides the 
overarching linkage between the strategic activities because it enables 
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collaborative learning and cross-functional communication. A key element of 
IPPD is the use of multi-disciplinary Integrated Product Teams (IPTs). The use 
of these teams is essential because each stakeholder provides a unique frame of 
reference and set of assumptions. Within the acquisition strategy, the program 
manager must properly orient and challenge the IPTs towards program 
objectives and empower them to reduce defensive barriers between functions 
and organizations (DSMC, 1999, p. 2-3). 


An IPT system and a program culture that emphasize collaborative 
learning will also help a program adapt to unknown-unknown risk factors. 
Unknown-unknown events can strike a program without warning, and a 
program’s ability to quickly adapt, learn, and develop collaborative solutions 
provides the most effective means to adapt to this type of risk factor. The IPTs 


serve as the facilitators of all strategic activities for the program. 


b. Risk Management 


The risk management process is dependent upon the program’s 
IPTs because the program requires multiple perspectives for risk identification. 
The DoD Risk Management Guide clearly states that risk identification is the 
responsibility of all members of the IPT, and it does not solely rest with the 
program manager or with the lead systems engineer (DoD, August, 2006, p. 7). 
The identification of risk encompasses all aspects of the acquisition program to 
include organizational, environmental, and technological. Risk management 
incorporates the concept of feed-forward, which Herbert Simon discussed as a 
key element of self-organization in The Sciences of the Artificial (Simon, 1981, p. 
44). 


The MGS program demonstrated that a limited self-organization is 
possible in the midst of a crisis, but this approach requires a substantial 
commitment of resources and, most importantly, organizational support. While 
there is no way to anticipate all risk, the program manager should ensure that the 
acquisition strategy integrates the risk management process with the systems 
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engineering process. A risk management process that identifies risk from both 
the bottom up and top down will help a program manager anticipate problems 


before they occur and to achieve greater stability and resilience. 


Cc. Systems Engineering 


Risk management is a key element of DoD acquisition doctrine that 
complements the systems engineering process. Like acquisition strategy, 
systems engineering covers all aspects of the program, but it primarily supports 
the acquisition strategy by establishing a common approach to the coordination 
of multi-disciplinary activities and processes. 


The use of the systems engineering process enables the program 
to develop a holistic view of development. The systems engineering process 
provides the overall plan that integrates both technical and business aspects of 
the program. Like the other strategic activities, the systems engineering process 
is dependent upon the program’s IPTs for the dissemination and interpretation of 
information. Timely and accurate decisions also depend upon accurate snapshot 
assessments of a system through test and evaluation. 


d. Test and Evaluation 


Test and evaluation is the program manager’s best method of 
determining the program’s actual technical status. Test and evaluation supports 
the acquisition strategy by assisting the program manager with revealing 
technical unknowns, which reduces the program’s overall level of risk. A 
program that establishes a culture where test and evaluation is an error- 
embracing process will view failures as critical to the learning process and 
continuous improvement. Therefore, error-embracing behavior should not take 
the form of a go/no-go or pass/fail test because this mindset will inevitably lead to 
unintended consequences. These consequences may include hiding bad results 
or limiting the scope of testing. All of the stakeholders, including the contractor, 
should take the perspective that embracing relevant failures will ultimately lead to 


an improved design that meets the user’s needs. 
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e. Contract Management 


Contract management supports acquisition strategy by shaping the 
contractor’s behavior to achieve the program’s objectives. It is also dependent 
upon an effective risk management process to ensure that the government and 
the contractor properly share risk. When planned and executed properly, 
contract management ensures that the processes used by the government and 
contractor are synchronized. Contract management is also the most tangible 
means of communicating the program manager’s strategic intent to the 
contractor. The program manager should also ensure that all of the program’s 
IPTs include a contract representative so that the contract can adapt to any 


changes to the environment in a timely manner. 


D. LESSONS LEARNED 


What follows is a_ short discussion of lessons learned and 
recommendations gleaned from this case study on MGS and its use of NDI. The 
inclusion of particular actions in these lessons and recommendations does not 
necessarily imply their absence or failure in the MGS program. Due to time and 
space constraints, the case study could not address all aspects of the program. 
Regardless, the intent of the lessons learned and recommendations is not to list 
what went wrong with the MGS, but rather to use the benefit of hindsight in a 
constructive manner and disseminate actionable items that are useful for any 


acquisition program. 


A To manage complexity, a program requires an acquisition 
strategy that is adaptable to the changes in the external and internal 
environment. 

a. Discussion: Complexity originates from outside of an acquisition 
program and each element of complexity interacts and influences a program 
through multiple risk factors. By itself, a risk factor may not pose a problem, but 
when multiple risk factors interact, a disaster may result. The central issue with 


complexity is uncertainty. Program management offices that find themselves 
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caught in the cauldron of fire-fighting problems with a crisis management 
approach have lost the initiative. From 2002 to 2004, the MGS program 
demonstrated a fire-fighting mentality in reaction to a number of developmental 
problems that included reliability shortfalls. The reliability problems were partly a 
symptom of the program’s inadequate acquisition strategy, which did not address 
the risk factors specific to the MGS. 

The ultimate objective of a program is to field a system, but this requires 
the program manager to create an acquisition strategy that can manage a broad 
continuum of uncertainty. The MGS PMO was able to reestablish the initiative 
after reinvigorating their systems engineering process through effective error- 
embracing behavior and collaborative learning. One factor that allowed this to 
occur was the institutional support that the MGS had from the user. 

b. Recommendations: 

e Program managers should develop and empower a strong IPPD 
because shared perspectives and interpretations across 
disciplines and processes is the key to managing complexity. 
Program managers should conduct periodic assessments of the 
operating environment assumptions and risk factors with key 
stakeholders. 

e Program managers should dedicate blocks of time on a 
recurring basis for a review of their program’s strategy. 
Program managers should dedicate one day two times per year 
to discuss the program’s acquisition strategy. The program 
manager should discuss a component or activity of the 
acquisition strategy on a monthly basis as an action item. 

e Program managers should form an informal Tiger Team or 
group of advisers to challenge program acquisition strategy. 
Program managers should form a diverse group in an informal 
advisory role to meet periodically to discuss how a program’s 


strategy is meeting its objectives. The purpose of this group is 
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to challenge and question the program manager in an effort to 
improve the resilience and quality of the strategy. 

e Acquisition strategy should focus on_ synchronization of 
activities. | Beyond discussing strategic activities such as 
systems engineering, risk management, test and evaluation, 
contract management, and IPPD as separate events, the 
acquisition strategy should describe how the program should 
synchronize activities to achieve program objectives. 

e Program managers should communicate the program’s 
acquisition strategy continuously to allow for greater 
decentralized decision-making capacity and alignment of 
program objectives. 

e During Acquisition Planning, program managers should include 
the acquisition strategy with the Request for Proposal (RFP) to 
increase the contractor’s awareness of the program’s approach. 


2. Systems integration is always something new and the effort it 
requires is frequently underestimated. The materiel developer should allot 
adequate time for systems integration during its development. 

a. Discussion: During its initial development period, the MGS PMO 
and GDLS did not use an adequate systems engineering process. One 
consequence was that the program did not have a clear picture of the technology 
readiness of the MGS Mission Equipment Package (MEP), particularly the 
ammunition handling system. The MGS required the integration of several major 
components including the low profile turret, the 105mm main gun, the 
ammunition handling system, and the fire control system. The MGS MEP was 
less technically mature than the MGS PMO anticipated, and this contributed to 
schedule delays and more testing. The MGS PMO soon determined that the 
integration of the major components required a more robust systems engineering 


process. 
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Recommendations 


During acquisition planning, the program manager should 
establish a Systems Engineering IPT (SEIPT) to oversee all 
technical planning. After awarding the contract, the SEIPT 
should become the Systems Engineering Integration Team that 
works across all IPTs to address technical aspects of the 
system. 

Prior to publishing the RFP, the program manager should 
ensure the program identifies potential high-risk requirements 
and/or Work Breakdown Structure components. 

During Source Selection, the government should prioritize the 
contractor's technical capabilities, particularly systems 
engineering, under Section M of the RFP, Evaluation Factors. 
Additionally, the government should ensure that it uses a highly 
experienced lead systems engineer when evaluating the 
contractor’s technical capabilities. 

The program manager should state within the Statement of 
Objectives (SOO) or Statement of Work (SOW) that the 
contractor’s systems engineering processes must be compatible 
with the government’s processes. 

The SOW/SOO should mandate the use of an integrated 
government/contractor configuration management process. 
Each engineering change can potentially trigger new problems. 
With engineers from multiple organizations working on the 
system, the program manager should emplace a disciplined 
configuration management plan that allows the program to 
diagnose problems during systems integration. 

The program manager should make the contractor’s systems 
engineering plan a Contract Data Requirement List (CDRL) 


item. 
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e /f the system requires development, then the RFP should 
require an assessment of technical readiness levels and 
integration readiness levels down to the third or fourth level of 
the Work Breakdown Structure. 

e The DoD should augment the Technical Readiness Assessment 
with an independent Integration Readiness Assessment. The 
Integration Readiness Assessment should provide a 
measureable Integration Readiness Level (IRL) that assists with 
determining the effort required for systems integration. 

e Program managers should approach systems integration as a 
bottom-up activity. Program managers should embrace a 
technical approach that integrates components on a small 
enough scale so that the program can discover problems as 
early as possible with sufficient time to diagnose them. 


3. The program manager should integrate a top-down/bottom-up 
risk management process with the systems engineering process. 

a. Discussion: Uncertainty is the fundamental problem for acquisition 
programs, and much of this uncertainty comes from the unpredictable interaction 
of risk factors. Program managers should not underestimate the importance of 
risk management, particularly in the early stages of a program. Systems 
engineering provides an integrated and multi-disciplinary approach to address a 
range of elements from the external continuum of factors, and a program should 
accompany systems engineering with an equally strong risk management 
process. The Risk Management Guide for DoD Acquisition clearly summarizes 
this idea: 

Additionally, risk management is most effective if it is fully 

integrated with the program's systems engineering and program 

management processes—as a driver and a dependency on those 


processes for root cause and consequence management. (DAU, 
August, 2006, p. 1) 
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Like the systems approach, risk management requires collaborative 
learning not only between the government and the contractor, but also with other 
key stakeholders such as the test and user communities. The ability to absorb a 
broad range of risk requires the program manager to anticipate problems, many 
of which fall into the unknown-known category. With unknown-known 
information, someone in the program may have the information that the program 
manager needs for a decision. Therefore, it is essential that the risk 
management process use both a top-down and a bottom-up approach to risk 
identification. 

In hindsight, it appears that the Army did not effectively employ a bottom- 
up risk management process at the beginning of the MGS program. Two 
potential reasons stand out for this shortfall. First, the MGS PMO did not have 
adequate staffing to conduct the risk management process given their 
involvement in the Interim Armored Vehicle source selection. Second, the IPT 
structure was not fully functional early in the program. 

b. Recommendations 

e The program manager should incentivize the contractor to 
integrate their risk management process with the government’s 
process. The integrated risk management process between the 
government and the contractor should collaborate as much as 
possible on information and common metrics. 

e The program manager should ensure that the contractor's risk 
management plan is a CDRL item, and that program integrates it 
with the systems engineering plan. 

e Government PMOs should empower the contractor throughout 
the risk management process in order to share risk and take 
ownership of the process. 

e The PMO should ensure that the Risk Management IPT has a 
written charter that it supports with Memorandums of 
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Understanding/Agreement between other governmental 
organizations/agencies and that it codifies within the contract. 

e The program manager should establish a risk management 
coordinator who works with the program's IPTs to identify risk. 
The risk management coordinator should assist the program 
manager with the risk management process. 

e The program manager should ensure that the lead systems 
engineer reviews the risk mitigation plans and the PMO should 
routinely update these plans. The program manager and lead 
systems engineer should carefully review the mitigation plan to 
determine the potential impact to other parts of the program. 

e The PMO should run a Risk Management Board on a recurring 
basis to review the risk management process and advise the 
program manager on risk. 

e Programs should make_ identified risks available to all 
stakeholders on a shared and collaborative database to improve 


risk visibility and program transparency. 


4. The integration of multiple NDI/COTS components will likely 
increase programmatic complexity. Program managers should carefully 
review the risks associated with materiel solutions that require the 
integration of NDI/COTS. 

a. Discussion: During the contract award briefing, LTG Kern, the 
Source Selection Authority stated: 

The mobile gun system takes a 105mm cannon which we already 

have and integrates it into the LAV chassis with a turret. And so off- 

the-shelf, in the context that we are speaking of, it means that there 

are integration efforts required for development, but we aren't 


designing new guns, sights, or sensor packages for this equipment. 
(Federal News Service, 2000) 
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A common misconception is that the use of NDI/COTS components 
correlates to a decrease in technical risk. However, program managers should 
carefully consider the risks associated with NDI/COTS. The IAV acquisition 
strategy mandated the use of NDI/COTS to reduce the technical risk (PM SBCT, 
2006, p. 106 and PM BCT, 2000, p. 8). With the MGS, the integration of multiple 
NDI/COTS increased the technical complexity because none of these 
components was plug- and- play and all required modification. 

Unless a system is immediately ready for fielding, meaning that it is truly 
off-the-shelf and immediately available, it will frequently require some level of 
development. The MGS proved that systems integration is unpredictable. Yet, a 
time-based acquisition strategy requires a much greater degree of certainty than 
the more typical event-based acquisition strategies. Applying a time-based 
strategy to a program that requires system development may successfully induce 
a greater sense of urgency, but it still imposes an arbitrary deadline on system 
fielding that does not reflect reality. 


b. Recommendations 
e During acquisition planning, the program manager should 


thoroughly conduct market research on NDI/COTS and carefully 
consider the trade-offs required in test and evaluation and 
schedule. Analyzing these factors will help the PM reduce risk. 

e Program managers should verify the contractor's test and 
evaluation processes for NDI/COTS prior to contract award. 
Government verification of contractor testing is necessary 
because the contractor testing may not replicate the item’s 
performance in a combat environment, and it may not replicate 
the military’s intended use of the item. 

e If the item is purely NDI or COTS, then the program manager 
should place the preponderance of contractual risk onto the 
contractor since the system is technically mature. 

e The program manager should ensure that the contract SOW or 


SOO clearly describes the means of verification for performance 
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specifications. Program managers should consult with multiple 
agencies on the most effective and efficient means of verifying 
performance specifications. 

e The PMO should ensure that it receives the Technical Data 
Package for all NDI to improve flexibility with systems 
integration, future upgrades, and logistical sustainment. 

e Programs should avoid combining developmental and non- 
developmental variants under the same acquisition strategy. 
Programs that require a developmental effort need a unique 
acquisition strategy that necessitates a different set of trade-offs 
in cost, schedule, and performance. 

e After verifying the contractor's testing process for NDI/COTS, 
the government should tailor the test and evaluation process 


around conditions not addressed by the contractor. 


5. The materiel developer, user, contractor, and test and 
evaluation communities should develop a culture of error-embracing 
behavior as the centerpiece of effective test and evaluation. 

a. Discussion: During the early stages of MGS delivery in 2002 and 
PQT in 2003, it became apparent that the ammunition handling system had 
significant problems, yet the Army did not verify these problems until much later 
in PQT (LTC Shane Fullmer, personal communication, February 27, 2009). 
Ultimately, the Army did not fully address these problems until late 2004, almost 
two years later. After the MGS PMO placed a high priority on improving the 
reliability of the MGS MEP, the test program achieved disciplined flexibility. 
When it became apparent that additional reliability growth was necessary, the 
PMO adjusted the Production Verification Test to allow for greater Reliability 
Growth Testing. The approach of disciplined flexibility allowed the PMO to 
address reliability shortcomings. 
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Error-embracing behavior goes beyond test and evaluation because it 


requires an aggressive organizational drive to find and root out system failures. 


A variation of this lesson learned is to confront the brutal facts as early as 


possible and to reduce the tendency to make less of problems. Clearly, test and 


evaluation is a continuous part of the systems engineering process, and it is a 


means of resolving whether the actual performance is meeting the expected 


performance. 


Error-embracing behavior is an attitude that discovery of test 


failures is desirable because the developer is learning how to improve the system 


design. 


b. Recommendations 


The program's test and evaluation strategy should complement 
the acquisition strategy by uncovering as many technical 
unknowns as possible. The structure of the test and evaluation 
strategy should provide the program manager with incremental 
amounts of information that will lead to improved decision- 
making. 

The Test and Evaluation Master Plan (TEMP) should allow for 
flexibility. lf the government believes that a_ particular 
component, particularly a critical element of a Mission 
Equipment Package, is inadequate, then the test program 
should address the problem as soon as possible. 

The Measures of Suitability outlined in the TEMP should 
adequately reflect the Operational Mission Summary/Mission 
Profile (OMS/MP) and they should provide a_ direct 
measurement of reliability, particularly for critical, high risk, 
components. 

Program managers should have incentive systems, both internal 
and external to the program, to create a culture where the early 
identification of problems and issues is highly encouraged. 
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e Program managers should implement event based test and 
evaluation that reflects the anticipated maturity of the system. 
Programs must verify the effectiveness and suitability of 


individual components before moving onto system level testing. 


6. Inadequate early and continuous planning for reliability leads 
to longer acquisition cycle times and higher lifecycle costs. 

a. Discussion: The MGS program experienced a crisis period in 
2004-2005 primarily because the reliability of the Mission Equipment Package fell 
short of the user’s requirements. The poor reliability was the result of an 
abbreviated systems integration process and a test and evaluation process that 
did not reveal reliability problems early enough. The MGS is not alone in 
demonstrating inadequate reliability, and one Army Test and Evaluation 
Command study of defense systems demonstrated that only 20% of the systems 
that underwent operational reliability testing from 1996-2000 met the reliability 
requirements (DoD, 2005, pp. 1-3). 

After attempting a test for reliability approach in 2003, the MGS PMO 
developed a design for reliability approach in 2004-2005. Additionally, the MGS 
PMO and GDLS implemented an improved Reliability Growth Testing process 
that incorporated a better tracking system for failure modes and a faster 
implementation of corrective actions. The MGS PMO and GDLS also integrated 
a design for reliability approach with the systems engineering process. 

b. Recommendations 

e During acquisition planning, the government should conduct an 
adequate engineering analysis of items identified during market 
research to determine the extent of integration required and the 
potential impact on system reliability. 
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The program manager should utilize the TRL/IRL assessment 
as an indicator of a potential problem with design for reliability. 
The TRL/IRL assessment should trigger an early focus on 
component level testing. 

Within the RFP, the program manager should include a 
Reliability Program Plan (RPP) that discusses the requirements 
for reliability and design for reliability approach. The RPP 
should require the contractor to provide a conversion of the 
reliability performance stated in the Operational Mode 
Summary/Mission Profile (OMS/MP) and Failure 
Definition/Scoring Criteria (FD/SC) to detailed specifications 
(Chang et al., 2009, p. 153). The RPP should also document 
the organizational roles and responsibilities for reliability 
activities and the procedures for verifying reliability requirements 
to include contingency plans for improving reliability (Office of 
the Deputy Under Secretary of Defense (A&T), 2009, p. 30). 
Future programs should adopt a design for reliability approach. 
If the program adopts an off-the-shelf system that requires 
systems integration, then the program manager should 
incorporate design for reliability into the systems engineering 
and test and evaluation plans because it will ultimately reduce 
the total ownership cost. 

The program manager should ensure the use of a closed-loop 
reporting system. The closed-loop reporting system ensures 
that the developer can properly record, track, and correct failure 
modes. The formation of a Failure Prevention and Review 
Board (FPRB) ensures that the developer can identify and 


address failure modes in a timely manner. 
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E. RECOMMENDATIONS FOR FURTHER RESEARCH 


1. During the MGS development, requirements changes occurred, 
starting in 2004. These requirements changes resulted in several Configuration 
Steering Boards (CSBs). The purpose of the Configuration Steering Board is to 
serve as an oversight committee that reviews requirements changes that have 
the potential of causing cost or schedule changes to ACAT | programs (Young, 
2007). Research is necessary to determine the root cause of the requirements 
changes and how the MGS PMO addressed the challenge. How does a 
program, like MGS, establish requirements discipline and limit configuration 
changes? 

2. Do contemporary acquisition programs properly align their strategic 
activities? Do these programs use the systems engineering, risk management, 
test and evaluation, contact management and IPPD processes in a 
complementary and reinforcing manner? 

3. Overcoming obstacles in the development effort can cause 
considerable delays and, depending upon their size and priority, they can also 
increase the program’s cost. Contractors are success-oriented and are anxious for 
the government to fully adopt their proposals and design solutions. The contractor 
has a natural tendency to make less of a developmental problem. How does the 
government, which is typically understaffed, diagnose the judgment of the 
contractors to determine the actual maturity of a system at the beginning of system 
development or during source selection? Does the government currently have the 
resources, including human capital, to conduct this effort? 

4. One option for programs that require a time-based approach is to 
conduct a non-linear approach to system development where the materiel 
developer, contractor, user, and the test community collaboratively agree under 
the auspices of the DoD to conduct parallel efforts. In the case of MGS, this 
might include building additional prototypes to allow for a broader test effort. The 
broader test effort would allow for simultaneous testing of multiple test events, 
which normally occur in sequence. While this process would be more chaotic 


and “messier” to manage, it might reduce the cycle-time of development. Such 
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an effort would require multiple waivers from the DoD as well as sufficient 
resources early on. Has the DoD developed a program using this approach? Is 


this approach feasible? 
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